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PREFACE 


The DMS-170 data management system clearly defines 
two roles: the role of a data administrator who 
develops, controls, and maintains the physical data 
base; and the role of an application programmer who 
accesses and manipulates the data within that data 
base- Although the two roles differ considerably, 
each role requires a knowledge of the tasks being 
performed by the other. The data administrator, 
for example, cannot develop a data base without 
first understanding what type of applications will 
be required. The application programmer, on the 
other hand, cannot successfully access data without 
first understanding how the data is described and 
what specific controls have been established. 

This guide describes the role of the FORTRAN 5 
application programmer who is accessing data within 
a DMS-170 controlled data base environment. The 
presence of a data administrator is assumed, and 
the functions associated with that position are 
described as they directly affect the application 
programmer. 

You should note that appendix C, entitled The 
Sample Application, is particularly important. 
This appendix sets up a working environment 
complete with stored data for use with sample 
programs. This environment can be duplicated to 
provide a better understanding of DMS-170 and the 
tools that are used to create a total data 
management system. 


The following manuals are of primary interest: 


Publication 


FORTRAN Data Base Facility 
Version 1 Reference Manual 

FORTRAN Version 5 Reference Manual 


As described in this publication, DMS-170 operates 
under control of the following operating systems: 

# NOS 1 for the CONTROL DATA CYBER 170 Series; 
CYBER 70 Models 71, 72, 73, and 74; and 6000 
Series Computer Systems. 

• NOS/BE 1 for the CDC CYBER 170 Series; CYBER 
70 Models 71, 72, 73, and 74; and 6000 Series 
Computer Systems. 


The NOS Manual Abstracts and the NOS/BE Manual 
Abstracts are instant-sized manuals containing 
brief descriptions of the contents and intended 
audience of all NOS and NOS product set manuals, 
and NOS/BE and NOS/BE product set manuals, 
respectively. The abstracts manuals can be useful 
in determining which manuals are of greatest 
interest to you. The Software Publications Release 
History serves as a guide in determining which 
revision level of software documentation 
corresponds to the Programming Systems Report (PSR) 
level of installed site software. 

As a FORTRAN 5 application programmer, you can find 
additional pertinent information in the listed 
Control Data Corporation publications. These 
publications are listed alphabetically in groupings 
that indicate relative importance to you as readers 
of this guide. 


Publication 
Number _ 


60482200 

60481300 


The following manuals are of secondary interest: 



Publication 

Publication 

Number 

CYBER Database Control System 

Version 2 Reference Manual 

60481800 

NOS Version 1 Manual Abstracts 

84000420 

NOS Version 1 Reference Manual, 

Volume 1 of 2 

60435400 

NOS/BE Version 1 Manual Abstracts 

84000470 

NOS/BE Version 1 Reference Manual 

60493800 

Software Publications Release 

History 

60481000 
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CDC manuals can be ordered from Control Data Corporation 
Literature and Distribution Services, 308 North Dale Street 
St. Paul, Minnesota 55103. 


This manual describes a subset of the features 
and parameters documented in the FORTRAN Data 
Base Facility Version 1 Reference Manual. 
Control Data cannot be responsible for the 
proper functioning of any features or 
parameters not documented in the FORTRAN Data 
Base Facility Version 1 Reference Manual. 
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NOTATIONS 


The specifications for FORTRAN DML statements and 
for particular control statements are described in 
reference formats. The notations used in the 
reference formats are described as follows: 


UPPERCASE Uppercase words are reserved words 
and must appear exactly as shown. 
You can use reserved words only as 
specified in the reference formats. 


Lowercase Lowercase words are generic terms 
that represent user-supplied words 
or symbols. 


C 3 Brackets enclose optional portions 

of a reference format. You can 
optionally omit or include all of 
the format within the brackets. 

... Ellipses immediately follow a pair 

of brackets to indicate that you 
can optionally repeat the enclosed 
material. 


Punctuation symbols shown within the formats are 
required unless enclosed in brackets and 
specifically noted as optional. One or more spaces 
separate the elements in a 
Numbers shown are decimal 
specified. 


reference format, 
unless otherwise 
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FORTRAN PROGRAMMING WITHIN DMS-170 


1 


DMS-170 Is a Control Data software package for data 
management. The system was designed on the premise 
that a data base should be centrally controlled and 
the data within that data base should be completely 
independent of application programs. In line with 
this philosophy, the role of data administrator 
emerged. This individual was to lead the design, 
programming, implementation, maintenance, and 
recovery efforts associated with the DMS-170 data 
management system. 

The data administrator is responsible for the 
structural organization and layout of an entire 
data base. This individual assigns names to and 
describes the characteristics of all data items 
within the data base. This total description is 
called a schema. The schema is generated by the 
data administrator and stored as a permanent file. 

As a FORTRAN programmer, you probably would never 
need or even want to access an entire data base. 
You would, however, need to access selected 
portions of a data base organized in a number of 
ways to meet the requirements of your various 
application programs. The grouping of data base 
items into separate data base portions is the 
responsibility of the data administrator. The 
descriptions of these grouped items are called 
sub-schemas. Sub-schemas are generated by the data 
administrator and stored in a permanent file 
library. 

Internal control is handled by the CYBER Database 
Control System (CDCS). CDCS interprets all data 
base requests from application programs, ensures 
the validity of such requests, and passes them 
along to the input/output processor. The controls 
exercised by CDCS guarantee that one user cannot 
alter the contents of the data base and adversely 
affect another user's program. 

The controls designated by the data administrator, 
incorporated into the schema and sub-schema, and 
carried out by CDCS relieve application programmers 
of many tedious tasks such as data description, 
data conversion, and validity checking. 

SYSTEM COMPONENTS 

The components of DMS-170 that are discussed in 
this guide include the language that describes the 
data (Data Description Language); the language that 
provides data base access to a FORTRAN application 
program (FORTRAN Data Manipulation Language); the 
module that controls data base activity (CYBER 
Database Control System); and the processor that 
handles all input and output operations (CYBER 
Record Manager). The components of DMS-170 that 
are not discussed in this guide include a special, 
nonprocedural language (Query Update) that provides 
data base access to programming and nonprogramming 
users and the COBOL Language extensions that 
provide data base access to COBOL application 
programs. 


DATA DESCRIPTION LANGUAGE 

The Data Description Language (DDL) is a compiler 
language that the data administrator uses to 
describe data. DDL can generate four types of 
descriptions: the schema definition that describes 
an entire data base; the FORTRAN sub-schema 
definition that describes selected portions of a 
schema-defined data base for use by a FORTRAN 
application program; the COBOL sub-schema 
definition that describes selected portions of a 
schema-defined data base for use by a COBOL 
application program; and the QUERY UPDATE 
sub-schema definition that either describes 
selected portions of a schema-defined data base or 
describes an independently controlled data base for 
use by the interactive query software product Query 
Update. The data descriptions for the schema and 
each sub-schema are declared in DDL source 
statements for input to the DDL compiler. 

A block diagram illustrating schema/sub-schema 
generation is shown in figure 1-1. 


The Schema 

The schema is a detailed description of all the 
data in a data base. The schema description is 
generated from DDL statements that name the schema, 
organize the schema into files (called areas in the 
schema), describe each record type together with 
the characteristics of the data in the record, and 
describe relationships (called relations) and 
dependency conditions (called constraints) among 
areas. The schema also includes an access control 
capability that provides privacy at the area level. 

The data administrator writes the DDL source 
statements and uses them as input to the DDL 
compiler for compilation into an object schema or 
schema directory. After storing the directory as a 
permanent file, the data administrator provides you 
with pertinent information so you can tailor your 
FORTRAN program to meet processing requirements. 
If, for example, you need to access an area that 
has been defined as having controlled access in the 
schema, it is the responsibility of the data 
administrator to supply you with the appropriate 
privacy key. 


The Sub-Schema 

The sub-schema is a detailed description of 
selected portions of the data in a data base. The 
FORTRAN sub-schema description is generated from 
DDL statements that identify the schema and 
sub-schema, specify files (called realms in the 
sub-schema) and the content and structure of 
records, indicate changes in data format required 
by the application program, identify relations to 
be used, and specify record qualification for 
relation processing. 
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Sub-Schema 
Library 


Figure 1-1. Schema and Sub-Schema Generation 


The data administrator writes the DDL source 
statements and uses them as input to the DDL 
compiler for compilation into an object sub-schema 
or sub-schema directory. After storing the 
directory in the sub-schema library, the data 
adninistrator provides you with a listing of the 
sub-schema so you can obtain the names and 
descriptions of the data to be referenced in your 
FORTRAN program. The data administrator also 
provides you with the name of the sub-schema 
Library, which you must attach with an operating 
system ATTACH control statement for DHL 
preprocessing of the Data Manipulation Language 
statements in your FORTRAN program just before 
compilation. 


FORTRAN DATA MANIPULATION LANGUAGE 

The FORTRAN Data Manipulation Language (DHL) is the 
language that provides a FORTRAN application 
program with access to the DMS-170 controlled data 
base. The Language consists of a series of 
statements that provide for opening and closing of 
data base files; reading, writing, updating, and 
deleting records from those files; and relation 
processing. The DML statements you include in your 
FORTRAN source program code are translated by the 
DML preprocessor into statements acceptable to the 
FORTRAN compiler. 


CYBER DATABASE CONTROL SYSTEM 

The central controlling component of DMS-170 is 
CYBER Database Control System (CDCS), which 
monitors and interprets all data base requests from 
application programs. CDCS preprocesses each 


application program request, performs any necessary 
data conversion, handles structural differences 
between the schema and the sub-schema by an 
operation called mapping, and prepares the request 
for input/output processing. 


Master Directory 

The master directory is a file that contains 
information relating to all data bases, schemas, 
and sub-schemas known to CDCS. The directory is 
generated by one of the data base utilities 
provided through CDCS. The data administrator 
creates the master directory and stores it as a 
permanent file. Your application program cannot 
reference a sub-schema unless information about 
that sub-schema exists in the master directory. It 
is the responsibility of the data administrator to 
ensure the sub-schema is valid. The master 
directory file is attached through the job stream 
of CDCS and is automatically available for your job. 

CDCS Batch Test Facility 

The CDCS Batch Test Facility is an absoLute program 
that you can use during program development and 
testing. The facility enables you to run CDCS as a 
normal batch job, which means you can attach a new 
version of the master directory file each time you 
run a job. 

The program, which resides on the system library, 
is called into execution by the CDCSBTF control 
statement. When using this facility, you are 
responsible for attaching the master directory file 
and any necessary log files each time you run a job. 
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Data Base Procedures 

Data base procedures are special-purpose subpro¬ 
grams that CDCS calls when specific situations 
occur during CDCS processing- The data admin¬ 
istrator writes the data base procedures and stores 
them in a permanent file Library. The name of the 
procedure, the point at which it is to be called, 
and the conditions governing its execution are 
specified in the schema definition- Loading of 
data base procedures is handled automatically 
for you. 


CYBER RECORD MANAGER 

CYBER Record Manager (CRM) is the processor that 
performs all input/output operations for FORTRAN as 
well as the other CYBER host languages operating 
within DMS-170. The Advanced Access Methods (AAM) 
file manager handles all operations concerning the 
physical storage and access of data by application 
programs. All data base files supported by CDCS 
are conventional CRM files. 

All necessary information regarding the 

characteristics of a data base file is supplied to 
CRM at schema compilation time. The data 
administrator specifies appropriate parameters on 
FILE control statements that are included in the 
DDL source deck when the schema is created. In 
DMS-170, all communication with CRM is handled 
automatically for you. 

A block diagram illustrating the CRM interface with 
CDCS and the data base is shown in figure 1-2. 


File Organization 

File organization information is stored in the 
schema directory. The three file organizations 


allowed for data base files that are to be accessed 
through CDCS are: indexed sequential, direct 
access, and actual key. 

Records in indexed sequential files are stored in 
ascending order by key. An application program can 
access the records either randomly by key or 
sequentially. 

Records in direct access files are stored randomly 
in fixed-length blocks. The number of the block to 
receive a record is determined by a calculation 
performed by the system on the record. An 
application program can access the records either 
randomly by key or sequentially. 

Records in actual key files have key values 
assigned by the system. The key value is a number 
that identifies the block and the position within 
the block in which the record is stored. An 
application program can access the records either 
randomly by actual key or sequentially. 

The primary key is specified in the schema. A 
listing of the sub-schema provides you with this 
information. 


Multiple-Index Processing 

Multiple-index processing is performed when 
alternate keys are defined for a file. An index is 
created for each alternate key in a data file when 
the file is created. The indexes are updated 
automatically whenever the data file is updated. 
An application program can retrieve the records by 
the primary key or by an alternate key. 

Each alternate key is specified in the schema. A 
Listing of the sub-schema provides you with this 
information. 



Figure 1-2. CYBER Record Manager Interface 
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SPECIAL FEATURES 

Eight special features with which you need to be 
familiar are: concurrency, immediate return, file 
privacy, relations, constraints, data base ver¬ 
sions, recovery, and data base transactions. When 
these mechanisms are present in the CDCS operating 
environment, some action on the part of your appli¬ 
cation program might be required. 


CONCURRENCY 

The concurrency feature allows two or more applica¬ 
tion programs to access the same data base file at 
the same time for retrieval or update purposes. 
During concurrent update operations, CDCS provides 
a locking mechanism by which files and records can 
be locked and unlocked at appropriate times. 

CDCS always locks the current record whenever the 
file is opened for input/output. Your application 
program, however, can issue explicit lock and 
unlock requests for CDCS to lock the entire file. 
By issuing a lock request, your program prevents 
other jobs from updating the file that it is using 
until it issues an unlock request. The file being 
locked and unlocked must be a file identified in 
the sub-schema. 

A deadlock situation can occur when a program 
attempts to access files or records that have been 
locked by CDCS for other programs. When this situ¬ 
ation occurs, CDCS arbitrarily releases the locked 
resources held by one of the contending programs. 
To ensure proper recovery handling in this type of 
situation, you should include appropriate code in 
your FORTRAN program. 


IMMEDIATE RETURN 

The immediate return feature of CDCS provides 
FORTRAN application programs with the ability to 
receive an immediate response from CDCS when either 
CDCS cannot get the resources it needs, or a fatal 
error occurs. When this feature is used, CDCS 
returns control to the application program. 

The immediate return feature cannot be enabled 
before CDCS is invoked. See the CDCS 2 Application 
Programming reference manual for more information. 


FILE PRIVACY 

The file privacy feature provides file access con¬ 
trol. When file privacy has been specified in the 
schema, your program must supply privacy keys to 
gain access to the file. 

The data administrator provides you with this 
information so you can ensure your FORTRAN program 
meets the privacy requirements when CDCS checks for 
appropriate privacy keys. 


RELATIONS 

The relational data base feature allows files to be 
linked together into a logical relationship called 


a relation. An application program can access the 
data from related files with a single read request. 
Relations are specified in the schema. Any rela¬ 
tion that is available to an application program is 
specified in the sub-schema. 

Your application program can access a relation by 
specifying a single read request with the name of 
the relation that is to be read. CDCS processes 
the request and returns a record occurrence from 
each file in the relation to your program's working 
storage area for the file. 

The data administrator can place limitations on 
relations by including restrictions in the sub¬ 
schema. Restrictions are in the form of qualifi¬ 
cation criteria that must be satisfied before a 
record occurrence is made available to your program. 

A listing of the sub-schema provides you with the 
name of the relation and indicates what specific 
restrictions apply. 


CONSTRAINTS 

The constraint feature allows controls to be imposed 
on update operations involving logically associated 
files. Constraints protect the integrity of the 
data base by allowing update operations to be 
performed only when specific conditions are satis¬ 
fied. Constraints are specified in the schema and 
are enforced by CDCS. 

The data administrator provides you with information 
concerning constraints. You can avoid constraint 
violations by becoming familiar with the rules that 
apply when modifying files on which constraints 
have been imposed. 


DATABASE VERSIONS 

The data base version feature of CDCS allows an 
application program to use the same schema and 
subschema to access more than one group of permanent 
files corresponding to the areas in the schema; 
each of these groups is defined as a data base 
version. Data base versions are defined by the 
data administrator in the master directory. By 
specifying use of different versions, an applica¬ 
tion program can perform operations on different 
groups of files, each group forming a data base 
version. For detailed information about this 
feature, see the CDCS 2 Application Programming 
reference manual. 


RECOVERY 

The recovery feature provides for reconstruction of 
a damaged or inconsistent data base and provides 
for the removing of updates made with erroneous 
logic. The data base can be recovered when physi¬ 
cal storage or system failure occurs and all or 
part of the data base is lost or otherwise unread¬ 
able. The data base can be restored to a previous 
checkpoint or beginning of job when an application 
program failure or logic error occurs. 
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Recovery operations are made possible through a 
logging facility, which is the recording of user 
interactions with a data base file. Logging 
requirements are defined by the data administrator 
for a schema and serviced by COCS, CDCS records 
the logging information on an independent file that 
ultimately serves as input for data base recover 
and restore operations. Log files, if specified, 
are attached through the job stream of CDCS and are 
automatically available to record the interactions 
of your program with the data base. 


DATA BASE TRANSACTION 

The data base transaction feature of CDCS provides 
the FORTRAN application program with the ability to 
group a series of data base updates into a logical 
unit, called a data base transaction. 

The application program specifies the beginning of 
the transaction, performs the update operations, 
and specifies the end of the transaction, which can 
be either a commit or a drop. When the application 
program specifies a commit operation, all updates 
made within the transaction become permanent. When 
the application program specifies a drop operation. 


all updates within the transaction are reversed; 
therefore, the data base remains in the state it 
was in before the beginning of the transaction. 

If the application program fails to commit a 
transaction because of system or program failure, 
automatic recovery is performed; that is, the 
transaction is dropped and the data base is re¬ 
stored to its state before the beginning of the 
transaction. 

Transaction processing also provides an application 
program with the ability to determine the point at 
which to restart processing after a system failure. 
The application program can use this feature to 
determine the last transaction that was committed 
before the system failure occurred. The program 
can then determine the point at which processing 
should be restarted. 

SUMMARY OF DMS-170 
COMPONENTS AND FEATURES 

A summary of DMS-170 components and features appears 
in table 1-1. This table provides a quick refer¬ 
ence for appropriate information. 


TABLE 1-1. SUMMARY OF DMS-170 COMPONENTS AND FEATURES 


Component/ 

Feature 

Definition 

Information 
Appears In 

Programmer Action 

Alternate key 

A key other than the primary key by 
which a file can be accessed; de¬ 
fined by the data administrator. 

Sub-schema Listing 

On a random read, set the key 
to a value indicating the 
desired record occurrence. 

CDCS Batch Test 
Facility 

A non-concurrent version of CDCS 
for use during program development. 

N/A 

Attach the master directory 
when executing the applica¬ 
tion program. 

Concurrency 

Simultaneous access to the same 
data by two or more application 
programs. 

N/A 

Include appropriate code in 
the application program to 
handle a deadlock situation; 
deadlock can occur when two 
programs are contending for 
access to a locked file or 
record. 

Constraints 

Controls imposed on records in 
associated files or on items in a 
single file to protect the integ¬ 
rity of the data base during update 
operations; defined by the data 
administrator. 

Schema 

Obtain information from the 
data administrator. Follow 
the rules for modifying 
files on which constraints 
have been imposed. 

CYBER Database 
Control System 
(CDCS) 

The central controlling module of 
DMS-170. 

N/A 

None. 

CYBER Record 
Manager (CRM) 

The input/output processor for 
DMS-170 operations. 

N/A 

None. 

Data base 
procedures 

Special-purpose routines that per¬ 
form predefined operations; written 
by the data administrator. 

Schema 

None. j 
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TABLE 1-1. SUMMARY OF DMS-170 COMPONENTS AND FEATURES (Contd) 


Component/ 

Feature 

Definition 

Information 

Appears In 

Programmer Action 

Data base 
transaction 

A series of update operations 
identified by a user-assigned 
transaction identifier. A trans¬ 
action is bracketed by a begin 
transaction operation and either a 
commit or drop operation. 

N/A 

Include appropriate code in 
the application program to 
bracket the series of update 
operations and to assign 
transaction identifiers. 
Transaction log files must 
have been defined by the data 
administrator in the master 
directory. 

Data base status 
block 

An array defined within an applica¬ 
tion program to which CDCS returns 
information concerning the status 
of operations on data base files 
and relations. 

N/A 

Include appropriate code in 
the application program. 

Data base 
version 

A set of permanent files that is 
associated with the areas described 
by the schema; defined by the data 
administrator. 

Master directory 

To use a data base version 
other than MASTER (which is 
otherwise assumed), specify 
the version name in the 
application program. 

Data 

Description 
Language (DDL) 

The language that is used to struc¬ 
ture a schema and sub-schema; used 
by the data administrator. 

N/A 

None. 

File 

organization 

The predetermined arrangement of 
stored data; indexed sequential/ 
direct access/ or actual key; 
defined by the data administrator. 

Schema 

None. 

File privacy 

A situation in which an application 
program can only gain access to a 
file by supplying a privacy key; 
defined by the data administrator. 

Schema 

Obtain information from the 
data administrator. Include 
a PRIVACY.statement in the 
application program. 

FORTRAN Data 
Manipulation 
Language (DML) 

The language that provides a 

FORTRAN application program with 
access to the DMS-170 controlled 
data base. 

N/A 

Include appropriate DML 
statements in the FORTRAN 
source program code. 

Immediate return 

A feature of CDCS that provides 
FORTRAN application programs with 
the ability to receive immediate 
response from CDCS when either 

CDCS cannot get the resources it 
needs/ or a fatal error occurs. 

N/A 

Include appropriate code in 
the application program. 

Log files 

Disk files on which user inter¬ 
actions with data base files are 
recorded for recovery purposes. 

Master directory 

None. 

Facility. 

Master 

directory 

A file containing information re¬ 
lating to all data bases, schemas, 
and sub-schemas known to CDCS; 
created by the data administrator. 

N/A 

Attach the master directory 
only when executing the pro¬ 
gram through the CDCS Batch 
Test Facility. 

Multiple-index 

processor 

A processor that allows CRM files 
to be accessed by alternate keys. 

N/A 

None. 
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TABLE 1-1. SUMMARY OF DMS-170 COMPONENTS AND FEATURES (Contd) 


Component/ 

Feature 

Definition 

Information 

Appears In 

Programmer Action 

Primary key 

A key that must be defined for 
a file when the file is first 
created; defined by the data 
administrator. 

Sub-schema listing 

On a random read, set the key 
to a value indicating the 
desired record occurrence. 

Recovery: 

Automatic 

A means by which a data base can 
be automatically recovered in case 
of a system or program failure. 

N/A 

Data base transactions pro¬ 
vide for automatic recovery; 
use them for sensitive up¬ 
dates. 

Recovery: 

Manual 

A means by which a damaged or 
destroyed data base can be re¬ 
constructed or restored; defined 
by the data administrator. 

N/A 

None. 

Relations 

Logical structures formed by the 
joining of files; permit retrieval 
of data from more than one file at 
the same time; defined by the data 
administrator. 

Sub-schema listing 

To read a relation, specify 
a single read request with 
the name of the relation. 
During update, follow the 
rules for updating files 
joined in a relation. 

Restrictions 

Criteria that must be satisfied in 
a relation before a record occur¬ 
rence can be made available to the 
application program; defined by the 
data administrator. 

Sub-schema listing 

None. 

Schema 

A detailed description of all the 
data in a data base; created by the 
data administrator through DDL. 

Schema listing 

None. 

Sub-schema 

A detailed description of selected 
portions of the data in a data 
base; created by the data adminis¬ 
trator through DDL. 

Sub-schema listing 

Attach the sub-schema 
library in which the sub¬ 
schema resides for DML 
preprocessing of the 
application program. 
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ACCESSING THE DATA BASE 


2 


Every DMS-170 data base file that is to be accessed 
through FORTRAN must be described in a directory 
called a FORTRAN sub-schema. The data admin¬ 
istrator, working with application programmers, is 
responsible for creating the sub-schemas. Every 
FORTRAN program that accesses a DMS-170 data base 
file must use the FORTRAN Data Manipulation 
Language (DML)• The application programmer is 
responsible for coding appropriate DML statements 
and including them in the FORTRAN source program. 

This section details the two principal data base 
access tools: the sub-schema that describes the 
data, and the language that provides access to that 
data. 

INTERPRETING THE FORTRAN 
SUB-SCHEMA 

The data administrator tailors sub-schemas to meet 
specific applications. Assume, for example, you 
have an application that requires access to only 
two fields in a data base file: student IDs and 
tuition charges. The data administrator might 
provide you with a sub-schema that resembles 
sub-schema SAMPLE1 shown in figure 2-1. 

With the exception of the sub-schema library name 
and any required privacy keys, the listing provides 
you with complete information. The handwritten 
notation in this example indicates the sub-schema 
Library name is DDLLIB. If you were planning to 
compile an application program using sub-schema 
SAMPLE1, you would need to attach DDLLIB. Since no 
privacy key is required, the schema obviously 
imposes no access control on realm ACCOUNT. 

Notice the three aliases assigned. Since symbolic 
names in FORTRAN cannot exceed seven characters and 
cannot include a hyphen, the data administrator 
changes the names for your application. 

Assume, for example, you have an application that 
requires access to two data base files. Assume, 
also, that you need a relationship between the two 
files so that you can search one file and retrieve 
corresponding records from the other. The data 
administrator might provide you with a sub-schema 
that resembles sub-schema SAMPLE2 in figure 2-2. 

The handwritten notation in this example indicates 
the sub-schema library name is DDLLIB. If you were 
planning to compile an application program using 
sub-schema SAMPLE2, you would need to attach 
DDLLIB. The schema apparently imposes access 
control on realm FILE2. The privacy key XX99 must 
be included in a DML PRIVACY statement to gain 
access to that realm. 


FORTRAN DATA MANIPULATION 
LANGUAGE 

The FORTRAN Data Manipulation Language (DML) is the 
means through which your FORTRAN program accesses 


the data base. You must code the DML statements 
along with FORTRAN statements in the FORTRAN source 
program. The DML statements identify the sub¬ 
schema, establish an interface with CDCS, and 
provide access to realms defined by the sub¬ 
schema. DML statements can appear both in the main 
program and in subprograms. 

The DML statements are translated into statements 
acceptable to the FORTRAN compiler. The DML 
preprocessor performs the translation and writes 
the translated statements to a file along with the 
FORTRAN statements in the source program. This new 
file is then the input file to the FORTRAN compiler. 

DML LANGUAGE COMPONENTS 

The DML language components include DML statement 
keywords, recognized symbols and punctuation, and 
user-supplied names of variables and constants. 
These components are grouped together into 
statements for input to the DML preprocessor, 
which translates each statement appropriately into 
a FORTRAN specification or CALL statement. 

The first word of a statement is always a DML 
keyword that identifies the task to be performed. 
Most keywords are followed by user-supplied 
elements and sometimes are followed by additional 
keywords. 

A list of available DML statements is shown in 
table 2-1 for reference purposes. The statements 
are listed in alphabetic order by the leading word 
(keyword), which identifies the purpose of the 
complete statement. The comments column provides 
specific rules for the statement and includes 
applicable default options. 


SYNTAX REQUIREMENTS 

The syntax requirements and coding conventions for 
DML statements are exactly the same as for FORTRAN 
statements. The following restrictions apply: 

• A DML statement cannot be the object of a 
logical IF. 

• A DML statement must not reference files that 
are referenced elsewhere in the program by a 
conventional FORTRAN input/output statement or 
by a FORTRAN PROGRAM statement. 

Any executable DML statement can have a statement 
label. The DML preprocessor copies the label into 
the translated FORTRAN statement. 

STATEMENT POSITIONING 

Some DML statements require special positioning 
within the FORTRAN source program. These require¬ 
ments are illustrated in figure 2-3. 


60483500 A 


2-1 




2-2 


60483500 A 




-o «T3 
COG 

(OM (O 


mTJ-1 
CJ CM 
£ « JU - g 

•»< S CM *{* 
Ea J u 

Sd c | 
,_u ' i‘s 
*3 £2 



0 

0 s- 

O 

LU 

LU 

*m CL) 

UJ 

_» 

Of 

M +4 

Of 

M 

r -4 

LU O 

CM 

Ll_ 

-J 

—1 <0 

—1 


M 

»-» s- 

M« 


U. 

U. (0 • 

u. 

to 

£ 

1 D 

■5S 

• • 1 4 -> 

XJ 


J- 

XJ 

1 - 

to 

O 

QJ»-I 

0 

QJ 

O 

W L- 

0 


a> 

(A C QJ 

a> 


s- 

g o 

u 

two 

to 

y « * 
* fe 

to 


QJ -C 

.g-o V 

Sr™ 

^ u flj 

uS « 
g-S * 

•—• *0 

j 1/1 a) 

M>f" n 

U- Z- 

■ 0 ° b 

$-11 to 

sg-s 

£~« 


z *—• o 

UJ CM<C 
oujo: 
m —I CD 


*T 3 ca 
qj • #» 
vi E .« 

SS§ 

ST* 


5 ”tE 

“VS" 

o J. u •*“ 

LU 2 ' _ 

ai '-i’Z. 

^ s 


c *- 
ea _ 

T- 


<0 

•-H 


<0 

-J 


to to 

UJ 


to 

Of 


ii 

XJ 


Q> 


uT 

t— 


0 *■: 

to 


CO 

0 


*1 

c 

XJ 


0 

0 J 

to 

•r- 

c 


+» 



(0 

0 

:.c x: 

r- 


0 u 

0 ) 


•t— 1 - 

L 

a> 


<c 

s- 

CO 


^ * . 
U *0 
p w <u 
CO XJ C 

0) s- u 
s- O 3 

O 4 -* 

a> a> 
«£ s- s- 


in 

1 - 



CO 



0 

m 

Mt 


0 

• 



• 

0 

CO 


UJ 

0 



a 

00 

Of 


X 

Ml 



Ml 

w 

UJ 


1 

1 

E 

U 

1 


> 


H* 

H* 

o 

UJ 

1 - 


Ml 


Z 

z 

-J 

X 

z 


z 

t- 

UJ 

111 

O 

| 

KU 

* 

o 

z 

a 

a 

O 

X 

O 


II 

UJ 

0 

0 

Ml 

X 

O 

CO 

< 

0 

1- 

h 

X 

0 

1 - 

z 

E 

0 

co 

CO 

X 

0 

co 

M 

111 

h 

II 

II 

0 

II 

(1 

J— 

X 

CO 

0 

a 

0 

0 

0 

CO 

0 

II 

UJ 

Ml 

II 

UJ 

Ml 

Ml 

CO 

T— 

X 

<r— 

CM 

X 

CM 

«J 

* 

UJ 

T— 

UJ 

UJ CM 

UJ 


CM 

_1 

-1 

J 

_J 

-1 

—J 

UJ 

UJ 

H 

w 

Ml 

IH 

Ml 

Ml 

0 

—J 

u. 

U- 

U- 

11 

u. 

LU 



JOE 

< U UJ 
UJ 111 l- 
X X M 
vw w 
(AW V) 

< < «t 


rs A 
E K ^ 
-JOE 
<U UJ 
U1 UJ K— 
OC Of H 
w v/ s/ 
WWW 

< «t < 


UJ 

X *- 
r- CM r* r- 

UJ UJ _J * 

_J _J Ml Of 

H H U. UJ 


EE Of 
_l _J O 

< < O 

UJ UJ UJ 

Of Of Of 


UJ 

ae * t- 

IM «- «- 

-I * * 


Of Of 

«t < 

X X 


0 . 1 - 1 1 

z co 

*H M < < 

h UJ UJ 

uj < x x 

o 1 - < < 

Of CO 


< ( 9(9 Of X 
uj z z h- o 

tf HHIOOCO 

< a. a. uj z 1 


xxx 

UJ 00 

CO 

0 0 

22 

3 

z 

Ml UJ 

CO 

Ml 

0 

1 - CO 
CO 

A O 

U. 

“> 

0 X 

X X 

0 


z 0 

0 0 


«— 

CD 

0 0 

0 

-J 

< 

UJ UJ 

z 

UJ 

Ml CM 

X X 

UJ 

X 

0 0 

-5 


«- cm to ^ in ^ h- 00 <* o *- cm ro ^ *n ^on 00 o o r- cm m in >o o p *- * * ^ in * 

OOOOOOOOO*-*-* - ▼“*— r- r- r- r* r- CM (\l (M N r* t- (\J N ♦ * fO N -jl 

oooaooopppoooo o 00 o p o 00 goggoo { * 00* 

SSSSaS29QQ999g Q 99 Q 2 Q 99 SS99S2t!SS! 

000000 


88888888 


8 8 8 88 


888888 


V 


CM 

CM 


CM 

ro 




UJ 



Ul 




>• 

>- 

>- 

_J 



-J 




UJ 

UJ 

Ul 

Ml 



Ml 




>- 

>- if 

if 

u. 



U- 




Ul 

UJ 



_l 

J 


-J 

—J 

-J 

if UJ 

if UJ 

UJ 

z 

< 

< 

Z 

< 

< 

c 

_ 1 - 

_ »- 

1 - 

Ml 

z 

Z 

IH 

z 

Z 

z 

>- «* 

>- c 

<c 

X 

Ml 

Ml 


Ml 

Ml 

Ml 

X z 

X z 

z 

K 

a 

O 

a 

O 

O 

< x 

< X 

X 

M 

X 

X 

Ml 

X 

X 

X 

E UJ 

E UJ 

UJ 

X 

0 

0 

X 

0 

O 

0 

•H 1 “ 

►H 1 - 

»- 








X -J 

X _J 

-J 


* * ao* 

**00* 


60483500 A 


2-3 




TABLE 2-1. DHL STATEMENTS 


Statement 

Description 

Comments 

ASSIGNID 

Obtains a restart identifier assigned 
by CDCS. 

The program must execute the ASSIGNID statement 
before processing data base transactions in order 
to determine the status of a data base transaction 
in a restart operation after a system failure 
occurs. The FINDTRAN statement is used in the 
restart operation. 

BEGINTRAN 

Begins processing of a data base 
transaction. 

Updates are considered temporary until the data 
base transaction is committed. 

CLOSE 

Ends processing of a realm. 

Realms can be opened and closed any number of 
times by a program. 

CLOSE relation 

Ends processing of the realms joined 
in a relation. 

Relations can be opened and closed any number of 
times by a program. 

COMMITTRAN 

Completes processing of a data base 
transaction. 

This statement causes all updates within the data 
base transaction to be considered permanent. 

DELETE 

Removes a record from a realm. 

The record being deleted is the record most 
recently read from the realm. The value of the 
primary key cannot change after the last read. 

DROPTRAN 

Cancels processing of a data base 
transaction. 

All realms are restored to the states that existed 
just before the data base transaction began. 

FINDTRAN 

Obtains information for a program 
restart operation after system 
failure. 

The program must have obtained a restart identifier 
by executing the ASSIGNID statement in order to use 
the FINDTRAN statement. 

INVOKE 

Establishes the interface between 
the executing program and CDCS. 

The statement must be executed before any other 

DML statements except SUBSCHEMA. 

LOCK 

Establishes an exclusive or protected 
lock on realms. Exclusive prohibits 
read and update operations on the 
realm. Protected prohibits only 
update operations (allows read 
operations). 

The realm must be a realm described in the sub¬ 
schema. 

NE INVERSION 

Changes the data base version being 
used by an application program. 

All sub-schema realms must be closed before 
executing the NEWVERSION statement. See the 

CDCS 2 Application Programming reference manual 
for details. 

OPEN 

Initiates processing of a realm. 

If the processing mode is not specified, the realm 
is opened for input/output. 

OPEN relation 

Initiates processing of the realms 
joined in a relation. 

If the processing mode is not specified, the rela¬ 
tion is opened for input/output. A processing 
mode of open for output only is not valid. 

PRIVACY 

Establishes the right of a program 
to access a realm. 

If the processing mode is not specified, the realm 
can be accessed for input/output. The mode must 
be the same as the mode indicated in the OPEN 
statement. 
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TABLE 2-1. DHL STATEMENTS (Contd) 


Statement 

Description 

Comment s 

READ 

Transfers data from a realm record 
to the variables defined in the sub¬ 
schema record description. 

If a key is not specified, the read is sequential. 

If a key is specified, the value of the referenced 
key must be set by the program before the read is 
executed. 

READ relation 

Transfers data from the relation 
records to the corresponding vari¬ 
ables defined in the sub-schema 
record descriptions. 

If a key is not specified, the read is sequential. 

If a key is specified, the key must be in the root 
realm; the value of the referenced key must be set 
by the program before the read is executed. 

REWRITE 

Replaces the last record read with a 
new record, using the current values 
of the variables defined in the sub¬ 
schema record description. 

The value of the primary key must not have changed 
since the last read. 

START 

Logically positions a realm for 
a subsequent sequential read 
operation. 

The processing mode must be either input or 
input/output. If a key is specified, it must be a 
primary or alternate key defined for the realm. 

If a key is not specified, positioning is by 
primary key. 

START relation 

Logically positions the root realm 
(the first realm named in the sub¬ 
schema) of a relation for a subse¬ 
quent relation read operation. 

The processing mode must be either input or 
input/output. If a key is specified, it must be 
a primary or alternate key that is defined in 
the root realm. If a key is not specified, 
positioning is by primary key of the root realm. 

SUBSCHEMA 

Identifies the sub-schema to be used 
by the program. 

A FORTRAN program can reference only one sub¬ 
schema. 

TERMINATE 

Terminates the interface between the 
FORTRAN program and CDCS. 

When a TERMINATE statement is issued, an INVOKE 
statement must be executed before any other DML 
statements are issued. 

UNLOCK 

Releases a lock on a specified realm 
and releases all record locks. 

The realm must be a realm described in the sub¬ 
schema. 

WRITE 

Writes a record, using the current 
values of the variables defined in 
the sub-schema record description. 

Schema record data items that are not defined in 
the sub-schema are given null values by CDCS. 
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^Specification statements 


SUBSCHEMA 


■Must appear here 


I-1 

DATA or NAMELIST statements 

I Statement function definitions . 


FORTRAN executable statements 

INVOKEt ^-[- 

ASSIGNIDt/FiNDTRANt j 

PRIVACYt ^-1_ 


BEGINTRAN - 

READ/WRITE/REWRITE/DELETE/START 

COKMITTRANl _ 

DROPTRAN f ^ 


I UNLOCK' | 

j CLOSET | 

j TERMINATE ^-|- 

|^F0RTRAN executable statements j 


■ Must precede other DML statements (except SUBSCHEMA statement) 


•Must precede OPEN statement 

■ Must precede LOCK statement 
•Must precede UNLOCK statement 

•Begins processing of a data base transaction 


•Ends processing of a data base transaction 


Must be last DML statement 


'Cannot appear within a data base transaction. 


Figure 2-3. DML Statement Positioning 
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PROCESSING THE DATA 


3 


Processing data base files within the DMS-170 
environment involves several steps. These steps 
are: 

1. Obtain a current listing of the sub-schema from 
the data administrator so you can have the 
names and descriptions of the data your program 
will be referencing. 

2. Obtain the name of the appropriate sub-schema 
library from the data acbninistrator. You will 
need to attach this library for preprocessing 
your program. 

3. Ask the data administrator if any realms in the 
sub-schema are defined in the schema as having 
controlled access. When access is controlled, 
you must know the privacy key. 

4. Ask the data administrator if any constraints 
exist in the schema. When constraints exist, 
CDCS enforces them by not allowing updates that 
violate constraints. 

5. Code the FORTRAN program and include 
appropriate Data Manipulation Language (DML) 
statements for opening, closing, and processing 
sub-schema realms. 

6. Preprocess and compile the FORTRAN program. 
Include, in the job stream before the FTN5 
control statement, an ATTACH control statement 
naming the sub-schema library and a DML control 
statement to execute the DML preprocessor. 

7. When compilation is successful, execute the 
FORTRAN program. Include an LDSET control 
statement to load the DMS-170 library. 

DML statements are available to perform a variety 
of operations on data base items described in a 
FORTRAN sub-schema. This section describes these 
statements and presents them in the following 
sequence: 

Data Base Access 
SUBSCHEMA 
INVOKE 
PRIVACY 
OPEN 

LOCK/UNLOCK 

CLOSE 

TERMINATE 

Data Base Manipulation 
WRITE 
READ 
START 
REWRITE 
DELETE 

Relation Access 

-OPEN- 

CLOSE 

READ 

START 


For purposes of illustration, a new sub-schema 
named AVERAGE is shown in figure 3-1. This 

sub-schema is referenced in subsequent examples. 
The examples show portions of program MODEL which 
illustrate statements necessary for particular data 
base operations. 

The sub-schema provides the following information: 

• The realm (file) to be accessed is named CFILE. 

• The record is named CRECORD. 

• A character item named IDENT is the primary key. 

• A character item named STUDENT is an alternate 

key. 

• A character item named COURSE is an alternate 

key. 

• A real item named GRADE is an alternate key. 

The handwritten notation on the listing indicates 
the sub-schema is stored on a Library named SSLIB. 
The notation also indicates CFILE has controlled 
access and requires a privacy key of XX99. 

USING DML TO ACCESS 
THE DATA BASE 

To access a data base, a FORTRAN program must 
identify the sub-schema that the program uses, 
establish an interface with CDCS, satisfy privacy 
requirements, and perform the usual functions of 
opening and closing files. The following para¬ 
graphs describe these functions and the DML state¬ 
ments that you include in your program to provide 
these functions. 


IDENTIFYING THE SUB-SCHEMA 

To identify the sub-schema, you must include a 
SUBSCHEMA statement in your program. This must be 
the first DML statement to appear in your program. 
The format is: 

SUBSCHEMACsub-schema-name) 

The SUBSCHEMA statement is required. You must 
position the statement in the program as follows: 

• After the specification statements 

• Before the first DATA or NAMELIST statement 

• Before any statement function 

• Before any executable statement 

At the point where the DML preprocessor encounters 
the SUBSCHEMA statement, the DML preprocessor 
copies into the source program the text declaration 
and DATA statements resulting from the sub-schema 
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AVERAGE 


* SOURCE LISTING * (80351) DDLF 1.2+538, 


** WITHIN CFILE 


** ORDINAL 


ORDINAL 


ORDINAL 


ORDINAL 


SUBSCHEMA AVERAGE,SCHEMA = UNIVERSITY 

ALIAS(REALM) CFILE=CURRICULUM 

ALIAS(RECORD) CRECORD=CURR-REC 

ALIAS(ITEM) STUDENT=STUDENT-ID.CURR-REC 

ALIAS(ITEM) COURSE=COURSE-ID.CURR-REC 

REALM CFILE 

RECORD CRECORD 


CHARACTER*14 IDENT 


CHARACTERS 1 STUDENT 
CHARACTER*6 COURSE 


REAL GRADE 


END OF SUB-SCHEMA SOURCE INPUT 


PRIMARY KEY 00012 
ALTERNATE KEY 00013 
ALTERNATE KEY 00014 
ALTERNATE KEY 00015 


IDENT FOR AREA CFILE 

STUDENT FOR AREA CFILE 

COURSE FOR AREA CFILE 

GRADE FOR AREA CFILE 

RECORD MAPPING IS NEEDED FOR REALM 


^ClMo/uj TiwrruL SSL1B. 
fcwimryJkey 'XX99*TwkdL f&l, CFJiE . 


Figure 3-1. Sub-Schema AVERAGE 


compilation. In this way, DML provides your 
program with the ability to reference all records, 
data items, and relations that are described in the 
sub-schema. 

In a program using the sample sub-schema AVERAGE, 
the SUBSCHEMA statement appears as shown in figure 
3-2. 


ESTABLISHING THE INTERFACE 
WITH CDCS 

To establish the interface with CDCS, you must 
include an INVOKE statement in your program. This 
must be the second DML statement to appear in your 
program. The format is: 

INVOKE 


PROGRAM MODEL 


CHARACTER ... 
DIMENSION ... 


SUBSCHEMA(AVERAGE) 
DATA ... 

DO ... 


Figure 3-2. Identifying the Sub-Schema 


The INVOKE statement is required. The statement 
must appear in the program before any other DML 
statement except SUBSCHEMA. 

When the INVOKE statement is executed, CDCS 
automatically attaches for use by the program all 
realms described in the sub-schema identified by 
the program. 

In a program using the sample sub-schema AVERAGE, 
the INVOKE statement appears as shown in figure 3-3. 


SATISFYING PRIVACY REQUIREMENTS 

If a realm is defined in the schema as having con¬ 
trolled access, your program must provide a privacy 
key to access the realm. To provide the privacy 
key, you must include the PRIVACY statement in your 
program. The format is: 
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PROGRAM MODEL 

CHARACTER ... 
DIMENSION ... 


SUBSCHEMA(AVERAGE) 

DATA ... 

DO ... 

• 

INVOKE 

m 

END 

Figure 3-3. Establishing the Interface With CDCS 

PRIVACY(reaIm-name, CMODE=mode,D 
PRIVACY=privacy key) 

where 

mode = I (access allowed for input) 


PROGRAM MODEL 


SUBSCHEMA(AVERAGE) 


INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACY= , XX99') 


END 


Figure 3-4. Satisfying Privacy Requirements 
where 

mode = I (open for input only) 

10 (open for both input and output, 
called input/output; default) 

0 (open for output only; valid only for 
creating a new file) 

s = label of an executable statement to 
which control transfers on open error 


10 (access allowed for both input 
and output, called input/output; 
default) 

0 (access allowed for output) 

privacy key = character constant, variable 
name, unsubscripted array name 

A privacy key can be from 1 through 30 characters 
in length. If you use a character constant to 
specify a privacy key, enclose the character string 
I in apostrophes. If you use a variable name to 
specify a privacy key, define the variable as type 
CHARACTER*30. Ensure that the privacy key is 
left-justified and blank filled in the field of the 
variable. If you use an array name to specify the 
privacy key, define the array as a 3-word array. 
Ensure that the privacy key is left-justified and 
blank filled in the field of the array. 

The PRIVACY statement is required when access is 
controlled. A separate PRIVACY statement is 
required for each realm defined with controlled 
access. The PRIVACY statement must be executed 
before the statement that opens the realm. 

The handwritten notation on the sample sub-schema 
listing (figure 3-1) indicates access to the realm 
is controlled and a privacy key called XX99 is 
required. In a program using the sample sub-schema 
AVERAGE, the required PRIVACY statement appears as 
shown in figure 3-4. 


OPENING A REALM 

Before your program can access any data records in 
an existing realm, the program must open the 
realm. To open the realm, you must include the 
OPEN statement in your program. The format is: 

OPEN(realm-name E,M0DE=mode3 C,ERR=s3) 


For a realm with controlled access, the mode of 
access indicated in the PRIVACY statement must 
provide for the access mode indicated in the OPEN 
statement. For example, if you open a realm for 
input (M0DE=I) you can specify M0DE=I0 in the 
PRIVACY statement. 

If a separate privacy key is required for input 
(M0DE=I) and another privacy key is required for 
output (M0DE=0), two PRIVACY statements are required 
to open a realm for input/output (M0DE=I0). 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), the OPEN statement appears as shown 
in figure 3-5. The MODE option is not included, 
indicating a default to input/output. 


PROGRAM MODEL 


SUBSCHEMA(AVERAGE) 


INVOKE 

PRIVACY(CFILE,MODE=IO,PRIVACY= , XX99 I ) 
0PEN(CFILE,ERR=100) 


100 PRINT *, 'ERROR ON OPEN 1 


END 


Figure 3-5. Opening a Realm 
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Both the PRIVACY and OPEN statements indicate the 
same mode, input/output. If an error occurs on 
open/ program execution continues at statement 100. 


LOCKING/UNLOCKING A REALM 

Whenever your program issues a read request on a 
realm that is open for input/output/ CDCS automat¬ 
ically locks the record that was read (the current 
record) against update by another user. Through 
DHL/ however/ your progam can prevent other jobs 
from performing update operations anywhere within a 
realm by issuing a request that CDCS lock the 
entire realm. To issue the lock request/ you must 
include the LOCK statement in your program. The 
format is: 

LOCK (realm-name C,TYPE=lock-type C/ERR=sD3) 
where 

lock-type = character constant or variable 

s = label of an executable statement to 

which control transfers on lock 
error 

Two types of Locking are permitted: exclusive or 
protected. Exclusive locking prohibits concurrent 
access to the realm for read or update operations; 
protected Locking allows concurrent access to the 
realm for read operations but prohibits concurrent 
update operations. 

Lock-type can be specified as either a character 
constant or a variable. The lock-type option must 
specify either the value EXCLUSIVE or the value 
PROTECTED. The Lock-type is 9 characters long. If 
you use a character constant to specify the lock- 
type/ enclose the character string in apostrophes. 
If you use a variable to specify the lock-type/ 
define the variable as type CHARACTER*9. 

The LOCK statement should be executed before any 
read request with intent to update the record. 

CDCS releases the realm lock held for your program 
when the program issues an unlock request. To 
issue the unlock request/ you must include an 
UNLOCK statement in your program. The format is: 

UNLOCK(realm-name C/ERR=s3) 

where 4 

s = label of an executable statement to which 
control transfers on unlock error 

You should judiciously use a realm lock. A realm 
lock Limits other users 1 access to the realm 
| (file). Additionally/ a realm lock overrides the 
CDCS record locking mechanism/ which provides a 
checking capability on rewriting and deleting 
records (for additional information, see the para¬ 
graphs Rewriting a Record and Deleting a Record). 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), the LOCK and UNLOCK statements appear 
as shown in figure 3-6. If an error occurs during 
the lock or unlock process, program execution 
continues at statement 200 or 300, respectively. 



Figure 3-6. Locking/Unlocking a Realm 


CLOSING A REALM 

When your program has completed processing on a 
realm, the program must close the realm. To close 
the realm, you must include the CLOSE statement in 
your program. The format is: 

CLOSE(realm-name C,ERR=s3) 

where 

s = label of an executable statement to which 
control transfers on close error 

Once a program closes a realm, the program can 
perform no further processing on the realm until it 
reopens the realm. 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), the CLOSE statement appears as shown 
in figure 3-7. If an error occurs on close, pro¬ 
gram execution continues at statement 400. 

TERMINATING THE INTERFACE 
WITH CDCS 

To terminate the interface with CDCS, you must 
include a TERMINATE statement in your program. The 
format is: 

TERMINATE 

Once the TERMINATE statement is executed, no fur¬ 
ther data base processing can take place without 
execution of another INVOKE statement. 
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In a program using the sample sub-schema AVERAGE 
(figure 3-1), the TERMINATE statement appears as 
shown in figure 3-8. This statement must be 
executed before the FORTRAN END or STOP statement. 

PROGRAM MODEL 

SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,MODE=IO,PRIVACY= 1 XX99 1 ) 
0PEN(CFILE,ERR=1Q0) 

LOCK(CFILE,ERR=200) 

UNLOCK(CFILE,ERR=300) 

CLOSE(CFILE,ERR=400) 

400 PRINT *, 1 ERROR ON CLOSE* 

END 

Figure 3-7. Closing a Realm 

PROGRAM MODEL 

SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACYs'XX99') 

0PEN(CFILE,ERR=100> 

CLOSE(CFILE,ERR=400) 

100 PRINT *, 'ERROR ON OPEN' 

400 PRINT *, 'ERROR ON CLOSE' 

TERMINATE 

END 

Figure 3-8. Terminating the Interface With CDCS 


USING DML TO MANIPULATE DATA 


DML statements are available to create, read, 
position, and modify data base records. The 
following paragraphs describe these functions and 
the DML statements that you must include in your 
program to provide these functions. 


WRITING A RECORD 

To write a complete record, you must include a 
WRITE statement in your program. The format is: 

WRITE(realm-name C,ERR=sD) 

where 

s = label of an executable statement to which 
control transfers on write error 


Before the WRITE statement is executed, the program 
must set the primary key and all alternate keys to 
appropriate values. A sub-schema does not always 
reflect all data items that appear in the schema 
record; therefore, before allowing the new record 
to be written to the data base, CDCS gives null 
values to those schema data items that are not 
defined in the sub-schema. 


In a program using the sample sub-schema AVERAGE 
(figure 3-1), the WRITE statement appears as shown 
in figure 3-9. The program sets the primary key 
IDENT and alternate keys STUDENT, COURSE, and GRADE 
to appropriate values before the WRITE statement is 
executed. If an error occurs on write, program 
execution continues at statement 500. 


PROGRAM MODEL 
SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACY='XX99') 
0PEN(CFILE,M0DE=I0,ERR=100) 

IDENT='122-13-6704-09' 

STUDENTS'122-13-6704' 

COURSES*PSY136' 

GRADE=3.7 

WRITE(CFILE,ERR=500) 


500 PRINT *, 'ERROR ON WRITE' 


900 CLOSE(CFILE) 
TERMINATE 
END 


Figure 3-9. Writing a Record 

This example shows a program writing a record to an 
existing file, CFILE. Before the program writes to 
this file, the PRIVACY and OPEN statements 
establish access for input/output (M0DE=I0). If 
the program were creating this file, the OPEN and 
PRIVACY statements would have to establish access 
for output only (M0DE-=0). 
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READING A RECORD 


To read a record, you must include a READ statement 
in your program- The format is: 

READ(realm-name C,KEY symbol item-name} 

C,ERR=sD C,END=s3) 

where 

symbol = = -EQ- -6T- -GE. 

item-name = primary or alternate key 

s = label of an executable statement to 

which control transfers on read 
error (ERR) 

label of an executable statement to 
which control transfers on 
end-of-file (END) 

When you omit the KEY option, the read operation is 
sequential- When you include the KEY option, the 
read operation is random. 

The END option is valid only for a sequential read 
Operation- 


Sequential Read 

A sequential read accesses the record occurrence 
located at the current record position- Successive 
read operations return record occurrences by 
position. Indexed sequential files are sequenced 
in ascending primary key order, actual key files 
are sequenced by block and record slot within the 
block, and direct access files are sequenced by 
position in home blocks. 

Typical FORTRAN 5 statements issued outside of a 
data base environment terminate with a fatal error 
if EOF is sensed and a test for EOF status is not 
included in the FORTRAN READ statement. If EOF 
status is not tested in DML, program execution 
continues with the next statement- Consequently, 
it is necessary to test for EOF on a DML sequential 
read operation- You can handle this test in one of 
two ways: 

• Include the END option on the READ statement. 
When EOF is sensed, program execution continues 
at the statement specified in the option. 

• Test for an EOF value of IOOq in the data 
base status block- This option is described in 
section 4. 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), a sequential read appears as shown in 
figure 3-10. If an error occurs on read, program 
execution continues at statement 600. The READ 
statement includes the END option to test for EOF. 
When EOF is reached, program execution continues at 
statement 900. 


Random Read 

A random read accesses a record occurrence by the 
value of a referenced primary or alternate key. 
The program must set the value of the referenced 
key before the READ statement is executed. 


PROGRAM MODEL 
SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACY='XX99 *) 
0PEN(CFILE,ERR=100) 

READ(CFILE,ERR=600,END=900) 


600 PRINT *, * ERROR ON READ’ 


900 CLOSE(CFILE) 
TERMINATE 
END 


Figure 3-10. Reading Sequentially 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), a random read appears as shown in 
figure 3-11. The program sets the alternate key 
GRADE to the value 4-0- This read returns from 
CFILE the first record occurrence in which the 
alternate key GRADE has the value 4.0. If an error 
occurs on read, program execution continues at 
statement 600. 


PROGRAM MODEL 
SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACY=’XX99') 
OPEN(CFILE,ERR=100) 

GRADE=4.0 

READ(CFILE,KEY-EQ.GRADE,ERR=600) 


600 PRINT *, ’ERROR ON READ* 


900 CLOSE(CFILE) 
TERMINATE 
END 


Figure 3-11- Reading Randomly 

POSITIONING A REALM 

To position a realm for subsequent sequential read 
operations, you must include a START statement in 
your program. The format is: 

START(realm-name C,KEY symbol item-name} 
C,ERR=s}) 

where 

symbol = = -EQ. .GT. -GE. 

item-name = primary or alternate key 

s = label of an executable statement to 

which control transfers on start 
error 

Before the START statement is executed, the program 
must have opened the realm for input or 
input/output. 
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When you omit the KEY option, the realm is 
positioned by primary key value; the realm is 
positioned to the record occurrence with a primary 
key value equal to the current value of the primary 
key item. When you include the KEY option, the 
realm is positioned to the first record occurrence 
with a matching key value. 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), both forms of the START statement 
appear as shown in figure 3-12. If an error occurs 
on start, program execution continues at 
statement 700. 


PROGRAM MODEL 
SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACY=*XX99’) 
0PEN(CFILE,ERR=1Q0) 

IDENT=’122-13-6704-01' 

START(CFILE,ERR=7Q0) 

READ(CFILE,ERR=600,END=900) 


700 PRINT *, ’ERROR ON START’ 


COURSE=’PSY1QO' 

START(CFILE,KEY.GE.COURSE,ERR=700) 
READ(CFILE,ERR=600,END=9G0) 


900 CLOSE(CFILE) 
TERMINATE 
END 


Figure 3-12. Positioning a Realm 

The first START statement omits the KEY option, 
which means CFILE will be positioned by primary 
key. The program sets the primary key (IDENT) to 
the value 122-13-6704-01 before the START statement 
is executed; the realm will be positioned to the 
record occurrence with the matching primary key 
value. 

The second START statement includes the KEY 
option. The program sets the alternate key COURSE 
to the value PSY100. The first record occurrence 
in CFILE with an alternate key COURSE greater than 
or equal to PSY100 will be the one to which CFILE 
is positioned. 


REWRITING A RECORD 

To rewrite a record, you must include a REWRITE 
statement in your program. The format is: 

REWRITE(realm-name C,ERR=s3) 

where 

s = label of an executable statement to which 
control transfers on rewrite error 


When a record is rewritten, the current values of 
those variables defined in the sub-schema are 
rewritten to the specified data base record. Data 
items defined in the schema but not defined in the 
sub-schema remain unchanged. 

Before your program can rewrite a record, your 
program must have locked the record either with a 
record lock or with a realm lock. Typically, the 
record Lock is used. 

For a rewrite using a record lock, the program 
establishes the record locking mechanism by opening 
the realm for input/output. To rewrite the record, 
the program must include the following steps: 

1. Read the record to the program’s working 
storage area by executing a DML READ statement. 

2. Set the value of each data item being changed 
to the appropriate new value. 

3. Rewrite the record by executing a REWRITE 
statement. 


When the realm is opened for input/output and the 
read is executed, CDCS expects an update operation 
and consequently locks the record. CDCS allows 
rewriting of only the locked record. 

The program must not change the value of the 
primary key between the read and the rewrite of the 
record. The following example illustrates a 
processing sequence to avoid: 

IDENT='100-22-5860-04’ 

READ(CFILE,KEY=IDENT) 

IDENT='200-44-7863-01’ 

REWRITE(CFILE) 


Assuming a rewrite using a record lock, CDCS does 
not allow the rewrite in this example to be 
performed because the record is not locked; 
record 100-22-5860-04 is locked, but the rewrite is 
attempted on record 200-44-7863-01. CDCS issues an 
error diagnostic on the rewrite. 

If an update requires that the value of a primary 
key be changed, the program must first delete the 
record with the old primary key value and then 
write the record with the new primary key value. 

For a rewrite using a realm lock, the program 

establishes the realm Lock by executing the LOCK 
statement. Then to rewrite a record, the program 
needs only to set the value of the primary key to 
the value of the record being rewritten and execute 
the REWRITE statement. The recommended rewriting 
procedure, however, includes more steps than 
these. The recommended procedure is the same as 

for a rewrite using a record lock: read the 

record, change the appropriate values, then rewrite 

the record. By reading the record, the program can 
test for an error on the read and, thereby, protect 
the integrity of the data base. With the realm 
lock, it is your responsibility to ensure that the 
program does not change the value of the primary 

key between the read and the rewrite of the record. 
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You should judiciously use a realm lock when 
rewriting records because the realm lock overrides 
the record lock and the checking capability 
available through the record lock. 

In a program using the sample sub-schema AVERAGE 
(figure 3-1), the REWRITE statement appears as 
shown in figure 3-13. The program performs the 
rewrite by using a record lock. The program reads 
the record occurrence with a primary key value 
of 100-22-5860-04, changes the value of data item 
GRADE to the value 3.8, and then rewrites the 
record. In the rewritten record, all other values 
in the record occurrence remain unchanged. If an 
error occurs on rewrite, program execution 
continues at statement 800. 


PROGRAM MODEL 
SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,MODE=IO,PRIVACY='XX99') 
OP EN(C FILE,ERR=100) 

IDENT= 1 100-22-5860-04 1 
READ(CFILE,KEY=IDENT,ERR=6Q0) 

GRADED.8 

REWRITE(CFILE,ERR=800) 


600 PRINT *, 'ERROR ON READ' 


800 PRINT *, 'ERROR ON REWRITE' 


900 CLOSE(CFILE) 
TERMINATE 
END 


Figure 3-13. Rewriting a Record 


DELETING A RECORD 

To delete a record, you must include a DELETE 
statement in your program. The format is: 

DELETE(realm-name C,ERR=sl) 

where 

s = label of an executable statement to which 
control transfers on delete error 

Before your program can delete a record, your 
program must have locked the record either with a 
record lock or with a realm lock. Typically, the 
record lock is used. 

For a delete using a record lock, the program 
establishes the record locking mechanism by opening 
the realm for input/output. To delete the record, 
the program must include the following steps: 

1. Read the record by executing a DML READ 
statement. 

2. Delete the record by executing a DELETE 
statement. 


When a realm is opened for input/output and the 
read is executed, CDCS expects an update operation 
and consequently locks the record. CDCS allows 
deletion of only the locked record. 

The program must not change the value of the 
primary key between the read and the delete of the 
record. The following example illustrates a 
processing sequence to avoid: 

ID ENT ='100-22-5860-04' 

READ(CFILE,KEY=IDENT) 

IDENT=»400-23-1248-07' 

DELETE(CFILE) 


Assuming a delete using a record lock, CDCS does 
not allow the delete in this example to be 
performed because the record is not locked; 
record 100-22-5860-04 is locked, but the delete is 
attempted on record 400-23-1248-07. CDCS issues an 
error diagnostic on the delete. 


For a delete using a realm lock, the program 
establishes the realm locking mechanism by 
executing the LOCK statement. Then to delete a 
record, the program needs only to set the value of 
the primary key to the value of the record being 
deleted and execute the DELETE statement. The 
recommended procedure for deleting a record, 
however, includes more steps than these. The 
recommended procedure is the same as for a delete 
using a record lock: read the record and then 
delete the record. By reading the record, the 
program can test for an error on the read and, 
thereby, protect the integrity of the data base. 
With the realm lock, it is your responsibility to 
ensure that the program does not change the value 
of the primary key between the read and the delete 
of the record. 


You should judiciously use a realm lock when 
deleting records because the realm lock overrides 
the record lock and the checking capability 
available through the record lock. 


In a program using the sample sub-schema AVERAGE 
(figure 3-1), the DELETE statement appears as shown 
in figure 3-14. The program performs the delete by 
using a record lock. The program reads from CFILE 
the record occurrence with a primary key (IDENT) 
equal to 100-22-5860-04 and then deletes that 
record. If an error occurs on delete, program 
execution continues at statement 850. 


USING DML TO PROCESS 
RELATIONS 

Relation processing greatly simplifies programming 
when several related realms are required by the 
application program. Realms that have common data 
items can be joined in a relation. When a relation 
is included in a sub-schema, the relation can be 
accessed and read through DML. This means that a 
single relation read request by an application 
program returns a relation occurrence, which 
consists of one qualifying record from each of the 
realms comprising the relation. 
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PROGRAM MODEL 
SUBSCHEMA(AVERAGE) 

INVOKE 

PRIVACY(CFILE,M0DE=I0,PRIVACY= , XX99') 

0PEN(CFILE,ERR=100) 

IDENT='100-22-5860-04' 
READ(CFILE,KEY=IDENT,ERR=600) 

DELETE(CFILE,ERR=850) 


600 PRINT *, 'ERROR ON READ' 


850 PRINT *, 'ERROR ON DELETE' 


900 CLOSE(CFILE) 
TERMINATE 
END 


Figure 3-14. Deleting a Record 

DML statements are available to provide for 
processing relations. The functions involved in 
relation processing are opening and closing the 
realms of the relation, positioning a relation 
through a start operation, and reading the 
relation. Paragraphs that follow describe these 
functions and the DML statements that you must 
include in your program to provide the functions. 
First, however, it is necessary to examine the 
structure of a relation and the manner in which 
CDCS returns records to the program's working 
storage area. 


STRUCTURE OF A RELATION 

A relation can be described as a hierarchical tree 
structure. The root of the tree is the realm 
through which the relation is entered; this is the 
first realm listed for a relation in the 
sub-schema. A data item in the realm at the root 
of the structure joins the realm to a common data 


item in the next realm listed for the relation. 
When the relation is entered, the value of the data 
item in the root realm record leads to a record in 
the second realm. More than one record in the 
second realm can contain the same value; thus one 
record in the root realm can lead to several 
records in the second realm. 

The second realm in the relation can be joined to a 
third realm through a common data item. Once 
again, a record in the second realm can lead to 
several records in the third realm. This branching 
out from the root of the tree continues through 
each realm in the relation. 

The tree structure of the three-realm relation REL3 
of the university data base is illustrated in 
figure 3-15. The tree structure is normally 
pictured upside down, with the root at the top and 
branches going down. The first realm, PFILE, which 
is the root of the structure, consists of a master 
record for each professor. The second realm, 

CRSFILE, consists of a master record for each 

course. The third realm, CFILE, consists of 

curriculum records. The common data item joining 
the first and second realms is the professor 
identification; the common data item joining the 
second and third realms is the course 

identification. 

Realms in a relation are numbered consecutively as 
ranks. The first realm entered (called the root 

realm) is always assigned rank 1. The rank is 

incremented by 1 for each successive realm in the 
relation. The value of the rank of a realm 
contrasts with the placement of the realm in the 

tree structure. The lower the rank, the higher the 
realm is shown in the tree structure; i.e., rank 1 

(the lowest rank) is shown at the top of the tree 
structure. Figure 3-15 also shows ranks in the 

relation REL3. 

When a relation is read, a record occurrence from 
each realm in the relation is returned to the 

program. A relationship exits between record occur¬ 
rences in a relation: a parent/child relationship. 
A record occurrence that has another record occur¬ 
rence at the next numerically higher rank in the 

relation is referred to as the parent record 



Figure 3-15. Tree Structure and Ranks of a Three-Realm Relation 
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occurrence. A record occurrence that has another 
record occurrence at the next numerically lower 
rank in the relation is referred to as the child 
record occurrence. In a parent/child relationship 
in relation REL3, a record occurrence in PFILE 
would represent the parent with corresponding record 
occurrences of CRSFILE representing the children. 
Additionally, a record occurrence in CRSFILE would 
represent the parent with corresponding record 
occurrences in CFILE representing the children. 

USING THE SUB-SCHEMA 

The structure of a relation is defined when the 
schema is created. A relation that is available to 
an application program is included in the 
sub-schema. The sub-schema listing provides the 
names of the realms in the relation. A new sample 
sub-schema named COMPARE, which makes available a 
three-realm relation, is shown in figure 3-16. 


The sub-schema listing provides the following 
information: 

• A relation is available to DML because the 
RELATION statement is included in the 
sub-schema. 


• Three schema areas are joined by relation named 
REL3. The areas are named PROFESSOR, COURSE, 
and CURRICULUM in the schema; they are renamed 
as realms PFILE, CRSFILE, and CFILE in the 
sub-schema. The order in which the areas 
(realms) appear in the Relation Statistics 
portion of the listing indicates the ranks of 
the realms: the first realm listed has the 
rank 1; the second, rank 2; and so forth. 


• PFILE has a primary key named PR0FI0; CRSFILE 
has an alternate key named PROF. Looking at 
the listing of aliases, you can see these 
fields both appear as PROF-ID in the schema. 
Obviously these fields represent unique 

professor identification and are common to both 
realms. You can assume that these items join 
the realms • The data administrator, however, 
should provide the common data items if they 
are not obvious and if programming con¬ 

siderations require that you know them. 


• CRSFILE has a primary key named CRSID; CFILE 
has an alternate key named COURSE. Looking at 
the listing of aliases, you can see these 
fields both appear as COURSE-ID in the schema. 
Obviously these fields represent unique course 
information and are common to both realms. You 
can assume that these items join the realms. 
The data administrator, however, should provide 
the joining data items under the conditions 
indicated previously. 


• A restriction is placed on CRECORD. A relation 
occurrence will not be returned unless data 
item CODE contains the character C. Before a 
relation occurrence is returned to the pro¬ 
gram's working storage area, CDCS checks for 
restrictions and enforces any restrictions. 
CDCS allows only qualifying records to be 
returned. 


OPENING A RELATION 

Before your program can access any data records in 
an existing relation, the program must open the 
appropriate realms. To open all the realms in a 
relation, you can include a relation OPEN statement 
in your program. The format is: 

OPEN (relation-name C,MODE=model C,ERR=s!]) 

where 

mode = I (open for input only) 

10 (open for both input and output, 
called input/output; default) 

s = label of an executable statement to 

which control transfers on open error 

Your program should normally open a relation for 
input (M0DE=I). The program should open the 
relation for input/output (M0DE=I0) under two 
circumstances: 

• Processing requirements indicate that the 
program should lock the records to prevent 
update during the relation read. 

• The program updates individual realms in the 

relation following the relation read. 

If your program is opening a relation in which one 

or more realms have controlled access, you must 

include in the program a PRIVACY statement for each 
realm that has controlled access. 

The following statement opens for input the realms 
joined in relation REL3, which is shown in sample 
sub-schema COMPARE (figure 3-16). If an error 
occurs on open, program execution continues at 
statement 50: 

0PEN(REL3,M0DE=I,ERR=50) 

If you have included an OPEN statement in your 
program for each realm in the relation, you do not 
need to include a relation OPEN statement. 


CLOSING A RELATION 

When your program has completed relation 
processing, the program must close the appropriate 
realms. To close all the realms of a relation, you 
can include a relation CLOSE statement in your 
program. The format is: 

CLOSE(relation-name C,ERR=s3) 

where 

s = label of an executable statement to which 
control transfers on close error 

The following statement closes the realms joined in 
relation REL3, which is shown in sample sub-schema 
COMPARE (figure 3-16). If an error occurs on 
close, program execution continues at statement 60: 

CL0SE(REL3,ERR=60) 

If you include a CLOSE statement in your program 
for each realm in the relation, you do not need to 
include a relation CLOSE statement. 
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COMPARE 


* SOURCE LISTING * (80351) DDLF 

00001 


SUBSCHEMA COMPARE.SCHEMA=UNIVERSITY 

00002 

00003 


ALIAS(REALM) PFILE=PROFESSOR 

00004 


ALIAS(RECORD) PRECORD=PROF-REC 

00005 


ALIAS(ITEM) PRO FID=PRO F-ID.PRO F-REC 

00006 


ALIAS(ITEM) PNAME=PROF-NAME 

00007 

00008 


ALIAS(REALM) CRSFILE=COURSE 

00009 


ALIAS(RECORD) CRSREC=COURSE-REC 

00010 


ALIAS(ITEM) CRSID=COURSE-ID.COURSE-REC 

00011 


ALIAS(ITEM) CRSNAME=COURSE-NAME 

00012 


ALIAS(ITEM) PROF=PROF-ID.COURSE-REC 

00013 


ALIAS(ITEN) FIELD=ACADEMIC-FIELD 

00014 

00015 


ALIAS(REALM) CFILE=CURRICULUM 

00016 


ALIAS(RECORD) CRECORD=CURR-REC 

00017 


ALIAS(ITEM) COURSE=COURSE-ID.CURR-REC 

00018 


ALIAS(ITEM) CODE=COMPLETE-CODE 

00019 


ALIAS(ITEM) DATE=COMPLETE-DATE 

00020 

00021 


REALM PFILE 

00022 


REALM CRSFILE 

00023 


REALM CFILE 

00024 

00025 


RECORD PRECORD 

** WITHIN PFILE 

00026 


CHARACTER*8 PROFID 

** ORDINAL 1 

00027 


CHARACTERS PNAME 

** ORDINAL 2 

00028 


CHARACTER+20 FIELD 

00029 

** ORDINAL 3 

00030 


RECORD CRSREC 

** WITHIN CRSFILE 

00031 


CHARACTER+6 CRSID 

** ORDINAL 1 

00032 


CHARACTERS CRSNAME 

** ORDINAL 2 

00033 


CHARACTER+8 PROF 

00034 

** ORDINAL 3 

00035 


RECORD CRECORD 

** WITHIN CFILE 

00036 


CHARACTER*!4 IDENT 

** ORDINAL 1 

00037 


CHARACTER*6 COURSE 

** ORDINAL 2 

00038 


CHARACTER+1 CODE 

** ORDINAL 3 

00039 


CHARACTER+8 DATE 

** ORDINAL 4 

00040 


REAL GRADE 

00041 

*★ ORDINAL 5 

00042 


RELATION REL3 

PRIMARY KEY 00026 

PROFID 

FOR AREA PFILE 

ALTERNATE KEY 00028 

FIELD 

FOR AREA PFILE 

PRIMARY KEY 00031 

CRSID 

FOR AREA CRSFILE 

ALTERNATE KEY 00033 

PROF FOR AREA CRSFILE 

PRIMARY KEY 00036 

ID ENT 

FOR AREA CFILE 

ALTERNATE KEY 00037 

COURSE 

FOR AREA CFILE 

ALTERNATE KEY 00040 

GRADE 

FOR AREA CFILE 

irk*** 

RECORD 

MAPPING IS NOT NEEDED FOR REALM - PFILE 

***** 

RECORD 

MAPPING IS NEEDED FOR REALM - CRSFILE 

***** 

RECORD 

MAPPING IS NEEDED FOR REALM - CFILE 

00043 


RESTRICT CRECORD (CODE .EQ. 'C') 

00044 


END 


Figure 3-16. Sub-Schema COMPARE (Sheet 1 of 2) 
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Figure 3-16. Sub-Schema COMPARE (Sheet 2 of 2) 


READING A RELATION 

To read a relation, you must Include a relation 
READ statement In your program. The format Is: 

READ(relation-name C,KEY symbol item-name] 
C,ERR=s] C,END=s3) 

where 

symbol = * .EQ. .GT. .GE. 

item-name = primary or alternate key 

s = label of an executable statement to 

which control transfers on read 
error (ERR) 

label of an executable statement to 
which control transfers on 
end-of-fite (END) 

When you omit the KEY option, the read operation is 
sequential. When you include the KEY option, the 
read operation is random. 

The END option is valid only for a sequential read 
operation. 


Sequential Relation Read 

A sequential relation read accesses the relation 
occurrence located at the current relation 
position. Successive read operations return 
relation occurrences by position of the root realm, 
which is the first realm Listed for the relation in 
the Relation Statistics portion of the sub-schema 
listing. Indexed sequential files are sequenced in 
ascending primary key order, actual key files are 
sequenced by block and record slot within the 
block, and direct access files are sequenced by 
position in home blocks. 

A relation occurrence is composed of record 
occurrences. A tree structure of record occur¬ 
rences for relation REL3 is shown in figure 3-17. 
Assuming that A1 is the first record in PFILE, the 
first and subsequent sequential reads return record 


occurrences to the working storage area in the 
following order: A1B1C1, A1B1C2, A1B1C3, A1B2C4, 
and so forth. When record occurrences in CRSFILE 
and CFILE are exhausted, a subsequent sequential 
read returns the next record (A2, not shown) in 
PFILE and associated records in CRSFILE and CFILE 
as the operation repeats. 


Typical FORTRAN 5 statements issued outside of a 
data base environment terminate with a fatal error 
if EOF is sensed and a test for EOF status is not 
included in the FORTRAN READ statement. If EOF 
status is not tested in a DML READ statement and 
EOF is sensed, program execution continues with the 
next statement. Consequently, it is necessary to 
test for EOF on a DML sequential read operation. 
This can be handled in one of two ways: 

• Include the END option on the READ statement. 
When an EOF is sensed, program execution 
continues at the statement specified in the 
option. 

• Include a test for an EOF value of IQOg in 
the data base status block. This option is 
described in section 4. 


In a program using sample sub-schema COMPARE 
(figure 3-16), a sequential read appears as shown 
in figure 3-18. If an error occurs on read, 
program execution continues at statement 600. The 
END option is included on the READ statement to 
test for EOF. When EOF is reached, program 
execution continues at statement 900. 

The sequential read returns the first record in 
PFILE and the first corresponding record occur¬ 
rences in CRSFILE and in CFILE. Successive reads 
return qualifying record occurrences as indicated 
in the preceding discussion of the tree structure 
of record occurrences. If EOF is sensed on PFILE, 
the relation read transfers control to the state¬ 
ment specified by the END option. 

Notice the PRIVACY statement. Since CFILE is 
joined in the relation and has controlled access, 
the privacy key for that realm is required. 
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PROGRAM RELMOD 


PROGRAM RELMOD 

SUBSCHEMA(COMPARE) 


SUBSCHEMA(COMPARE) 

INVOKE 


INVOKE 

PRIVACY(CFILE,MODE=I,PRIVACY='XX99') 


PRIVACY(CFILE,M0DE=I,PRIVACY= , XX99 I ) 

0PENCREL3,M0DE=I,ERR=100) 


OPEN(REL3,M0DE=I,ERR=100) 

READ < REL3,ERR=600,END=900) 


PROFID^RSSOOSdO* 

• 

■ 

READ(REL3,KEY=PR0FID,ERR=600) 

900 CL0SE(REL3) 

■ 

- 

TERMINATE 


900 CLOSE(REL3) 

END 


TERMINATE 


■ 

END 


Figure 3-18. Reading a Relation Sequentially 

Random Relation Read 

A random relation read accesses a relation 
occurrence by the value of a referenced primary or 
alternate key. The referenced key must be in the 

root realm. For a program using the sample 

sub-schema COMPARE, the key named in the READ 
statement must be associated with PFILE (the root 
realm) rather than CRSFILE or CFILE. The program 
must set the value of the referenced key before the 
READ statement is executed. 

In a program using sub-schema COMPARE 
(figure 3-16), a random read appears as shown in 
figure 3-19. The program sets the primary key 
PROFID of PFILE to RSS00860. The random read 
returns the record occurrence in PFILE that has 

PROFID equal to RSS00860 and the first 

corresponding record occurrences in CRSFILE and 
CFILE. 


Control Break 

A control break occurs when a new record occurrence 
is read for a parent realm in a relation. Control 
break status, however, is returned for the realm of 
the child. Therefore, if a realm in a relation has 
control break status after execution of a 
sequential read, the record occurrence read for 
this realm is a child record occurrence for a new 
parent record occurrence. 


Figure 3-19. Reading a Relation Randomly 

In the example shown in the tree structure of 
record occurrences (figure 3-17), control break 
occurs when A1 is first read (when A1B1C1 is 
returned). In this situation, control break status 
is returned for CRSFILE (rank 2) and for CFILE 
(rank 3). A control break occurs when B2 is first 
read (when A1B2C4 is returned), when B3 is first 
read (when A1B3C6 is returned), and so forth. In 
these situations, control break status is returned 
for CFILE, which is rank 3 of the relation. 

The presence of a control break and the rank of the 
realm that is the lowest ranked realm with control 
break status can be determined by checking the data 
base status block. Status checking is described in 
section 4. 


Null Occurrence 

A null occurrence denotes that either no record 
occurrence qualifies for a read or that a record 
occurrence does not exist at a given level in a 
relation. 

A read relation operation produces a null 

occurrence when one of the following is true: 

• A parent record occurrence qualifies for the 

read, but no child record occurrence qualifies. 

• A parent record occurrence qualifies for the 

read, but no child record occurrence exists. 
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If a null record occurrence is returned for each 
realm in a relation except the root realm, another 
READ statement must be executed to obtain the next 
set of record occurrences. 

A null occurrence consists of a display code right 
bracket ( 1 ) in each character position of the 
record in the working storage area. The presence 
of a null occurrence and the lowest rank on which 
it occurred can be detected by checking the data 
base status block. Status checking is described in 
section 4. 

Some examples of null record occurrences returned 
are shown in figure 3-20. In the first example, 
the lowest rank with a null record occurrence is 
rank 2. In the second and third examples, the 
lowest rank with a null record occurrence is rank 3. 


Before the START statement is executed, the realm 
must have been opened for input or input/output. 

When you omit the KEY option, the relation is 
positioned by primary key value of the root realm; 
the root realm is positioned to the record 
occurrence with a primary key value equal to the 
current value of the primary key item. When you 
include the KEY option, the root realm is 
positioned to the first record occurrence with a 
matching key value. 

In a program using the sample sub-schema COMPARE 
(figure 3-16), both forms of the START statement 
appear as shown in figure 3-21. If an error occurs 
on start, program execution continues at 
statement 7Q0. 


POSITIONING A RELATION 

To position a relation for subsequent sequential 
read operations, you must include a START statement 
in your program. The format is: 

START(relation-name C,KEY symbol item-name! 
C,ERR=s!) 


The first START statement omits the KEY option, 
which means the relation ocurrence will be 
positioned by the root realm primary key. The 
primary key (PROFID) of the root realm is set to 
the value MLNQ0840 before the START statement is 
executed; the relation is positioned to the root 
realm record occurrence with the matching primary 
key. 


where 

symbol = = .EQ. .GT. .GE. 

item-name = primary or alternate key defined in 
the root realm 

s = label of an executable statement to 

which control transfers on start 
error 


The second START statement includes the KEY 
option. Alternate key FIELD is set to the value 
PSYCHOLOGY. The first record occurrence in PFILE 
with an alternate key equal to PSYCHOLOGY is the 
one to which root realm PFILE is positioned. The 
subsequent sequential reads reference the alternate 
key FIELD. These reads return record occurrences 
in the root realm in alphabetical order (collating 
sequence order) according to the value of the 
alternate key FIELD. 


Record Occurrences in a Relation 


Rank 1 


Rank 2 


Rank 3 



A1 qualifies, B1 and B2 do not qualify. 


Program's Working Storage Area 

A1 

11 .. .3 

11...1 

A1 and B2 qualify. 




Program's Working Storage Area 

A1 

B2 

11...1 

A1 and 81 qualify. Cl, C2, and C3 do not qualify. 

Program's Working Storage Area 

A1 

B1 

11...1 


Figure 3-20. Null Record Occurrence Examples 
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PROGRAM RELMOD 
SUBSCHEMA(COMPARE) 

INVOKE 

PRIVACY(CFILE,M0DE=I,PRIVACY= , XX99 I ) 
OPEN (REL3,M0DE=I,ERR=100) 

PROFID='MLN00840 1 

START(REL3,ERR=700) 

READ(REL3,ERR=600,END=9Q0) 


FIELD= 1 PSYCHOLOGY 1 

START(REL3,KEY.EQ.FIELD,ERR=7Q0) 

READ(REL3,ERR=650,END=750) 


900 CLOSE(REL3) 
TERMINATE 
END 


Figure 3-21. Positioning a Relation 


UPDATING REALMS JOINED IN A 
RELATION 

Realms joined in a relation can be updated, but 
care should be exercised. Related files are joined 
in the schema by a common data item to form a 
parent/child relationship. The schema contains a 
JOIN clause in which a data item in one realm is 
equated with an identical data item in another 
realm. This common data item is called a join item. 

CDCS normally does not monitor update operations 
that would alter the underlying relationship 
between related files. The exception is when con¬ 
straints have been incorporated in the schema by 
the data administrator, as described in section 4. 

Assuming constraints are not present, the following 
precautions should be noted: 

• Modification of join item values can change 
parent/child relationships. 

• Deletion of parent record occurrences can make 
all child record occurrences of the deleted 
parent record occurrence inaccessible when a 
relation is read. 

Important rules to remember for relation update are: 

• Always delete a child occurrence before delet¬ 
ing the parent record occurrence. 

» Always write the parent record occurrence 

before writing a child record occurrence. 

• Be aware of file positioning; input/output 
operations could alter positions on the files 
joined in the relation while within a sequen¬ 
tial read relation loop. 


USING DML TO PROCESS 
DATA BASE TRANSACTIONS 

Data base transactions can be used when you have 
many interrelated updates to perform on one or more 
data base files. These updates all need to be 
processed and made permanent to ensure the data is 
correct before other users access the updated 
records. A data base transaction is a convenient 
way for processing coordinated updates. 

A group of updates for which the application pro¬ 
gram specifies the beginning and the completion is 
referred to as a data base transaction. At first, 
all updates within a data base transaction are 
considered temporary. These updates are considered 
permanent when the application program specifies 
the completion of the data base transaction (called 
committing a data base transaction). Figure 3-22 
shows the sequence of operations in a data base 
transaction. 

If an application program does not commit a data 
base transaction, but instead drops the data base 
transaction or terminates execution, each record 
that was updated within the data base transaction 
is restored to the state it was in just before the 
beginning of the data base transaction, and CDCS 
issues an informative diagnostic. There are several 
situations in which data base transactions are not 
committed. For example, program logic can deter¬ 
mine that the data base transaction should not be 
committed and can cancel (drop) the data base 
transaction. System failure or program failure can 
occur during the application program's processing 
of the data base transaction. In each of these 
situations, updates made within the uncommitted 
data base transactions are reversed. 

The application program can perform data base 
transactions only if transaction recovery files 
have been defined for the schema in the master 
directory. When a FORTRAN application program 
begins a data base transaction, CDCS processes 
subsequent update operations by that program in 
transaction mode. When processing in transaction 
mode, CDCS uses the exclusive record locking mech¬ 
anism that prevents other users from accessing 
records updated within an uncommitted data base 
transaction. 


PROCESSING OPERATIONS 

FORTRAN DML statements provide for the operations 
involved in data base transactions. Three of these 
operations, which are directly involved in the 
program code dealing with updates, are described in 
the following paragraphs. 

• Begin a data base transaction 

Designates the beginning of a data base 
transaction and communicates a transaction 
identifier to CDCS. This causes CDCS to 
begin processing in transaction mode for 
the application program. 
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COMMITTRAN 


Figure 3-22. Data Base Transaction Flow 


• Commit a data base transaction 

Designates the end of a data base trans¬ 
action and indicates that the updates 

within the data base transaction are to be 
committed. This causes all the updates 
made within the data base transaction to be 
considered permanent. 

• Drop a data base transaction 

Designates the end of a data base trans¬ 
action and indicates that the updates 

already made within the data base trans¬ 
action are to be cancelled. This causes 
each record updated within the data base 
transaction to be restored to the state it 
was in just before the beginning of the 
data base transaction. 


Beginning a Data Base Transaction 

To begin a data base transaction, you must use a 
BEGINTRAN statement. The format is: 

BEGINTRAN (tran-id C,ERR=s3) 

where 

tran-id - character constant or variable 

s = label of an executable statement to 

which control transfers on begin error 


A tran-id can be from 1 through 10 characters in 
length. If you use a character constant to specify 
a tran-id, enclose the character string in apostro¬ 
phes. If you use a variable name to specify a 
tran-id, define the variable as- type CHARACTER*10. 
Ensure that the tran-id is left-justified and blank 
filled in the field of the variable. 

Records that are subsequently updated remain 
exclusively locked until the data base transaction 
is either completed or dropped. Updates are con¬ 
sidered temporary until the data base transaction 
is successfully completed. If your program attempts 
to begin a data base transaction when the data ad¬ 
ministrator has not defined a transaction recovery 
file for the schema, a fatal error occurs. 


Committing a Data Base Transaction 

To commit a data base transaction, you must use a 
COMMITTRAN statement. The format is: 

COMMITTRAN C(,ERR=s)T 

where 

s = label of an executable statement to which 
control transfers on commit error 

Execution of this statement causes all updates of 
the present data base transaction to become perma¬ 
nent; alt record locks are released so that the 
records become available for access by other appli¬ 
cation programs (unless a realm lock applies). 
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In a program using sample sub-schema COMPARE (figure 
3-16), the BE6INTRAN and COMMITTRAN statements 
appear as shown in figure 3-23. The program uses 
the BEGINTRAN statement to begin the data base 
transaction. The program sets the primary key 

PROFID of PFILE to WLSN0855. PFILE is read randomly 
and the occurrence of this record is deleted. A 
new record is then written to PFILE. The CRSFILE 

is read randomly for any occurrence of the deleted 
PROF value. Each record with PR0F=WLSN0855 is 

updated and rewritten with the PROF value of the 

new record. After all updates have been performed, 
the COMMITTRAN statement is executed and all up¬ 
dates become permanent. 


PROGRAM RELMOD 
CHARACTER TRANID *10 
SUBSCHEMA(COMPARE) 

DATA TRANID/'1234567890V 
INVOKE 

PRIVACY (PFILE,M0DE=I0,PRIVACY='XX99') 
OPEN(PFILE,M0DE=I0,ERR=600) 

OPEN(CRSFILE,MODE=IO,ERR=60O) 

BEGINTRAN (TRANID,ERR=900) 

PR0FID='WLSN0855' 

READ(PFILE,KEY=PROFID,ERR=600) 

DELETE(PFILE) 

PROFID= 1 MRHT1234 1 
PNAME='HAUS, M.T.' 

FIELD 52 * CHEMISTRY* 

WRITE(PFILE,ERR=600) 

DO 400, 11=1,10 
PR0F=*WLSN0855 * 

READ(CRSFILE,KEY=PROF,END=500,ERR=600) 
PR0F=*MRHT1234* 

400 REWRITE(CRSFILE,ERR=600) 

500 COMMITTRAN(ERR=600) 


900 CLOSE(PFILE) 
CLOSE(CRSFILE) 
TERMINATE 
END 


Figure 3-23. Committing a Data Base Transaction 


Dropping a Data Base Transaction 

To cancel the current data base transaction, you 
must use a DROPTRAN statement. The format is: 

DROPTRAN C(,ERR=s)D 


where 

s = label of an executable statement to which 
control transfers on cancel error 


Execution of the DROPTRAN statement causes CDCS to 
restore the records updated within the data base 


transaction to their original states that existed 
just before the data base transaction was initiated 
and also causes CDCS to release all record locks. 


In a program using sample sub-schema COMPARE (figure 
3-16), the BEGINTRAN and DROPTRAN statements appear 
as shown in figure 3-24. The program uses the 
BEGINTRAN statement to begin the data base transac¬ 
tion. If an error occurs in the program, execution 
continues at line 600 and the DROPTRAN statement is 
executed, causing the current data base transaction 
to be cancelled. 


PROGRAM RELMOD 
CHARACTER TRANID *10 
SUBSCHEMA(COMPARE) 

DATA TRANID/'1234567890 V 
INVOKE 

PRIVACY (PFILE,M0DE=I0,PRIVACY=*XX99*) 
OPEN(PFILE,M0DE=I0,ERR=600) 

OPEN(CRSFILE,M0DE=I0,ERR=600) 
BEGINTRAN (TRANID,ERR=900) 


READ(PFILE,KEY=PR0FID,ERR=600) 


WRITE(PFILE,ERR=6Q0) 


600 PRINT*, 'TRANSACTION ERROR' 
DROPTRAN 
900 CLOSE(PFILE) 

CLOSE(CRSFILE) 

TERMINATE 

END 


Figure 3-24. Dropping a Data Base Transaction 


PROCESSING CONSIDERATIONS 

The following rules and considerations apply to 
data base transactions: 

• Only one data base transaction can be in prog¬ 
ress at a time within a particular application 
program. That is, there can be no nesting of 
data base transactions. 


• The data administrator defines the maximum 
number of concurrent data base transactions 
allowed for all users of the schema. If this 
number is exceeded, CDCS issues a nonfatal 
diagnostic. The application program can try 
the data base transaction request later. 


• File locks are not recommended for use with 
data base transactions. 
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USING DML FOR PROGRAM 
RESTART 

FORTRAN DML statements provide for the operations 
involved in restarting programs. The restart 
component of data base transactions allows an 
application program to determine the point at which 
to begin a data base transaction following a system 
failure. An application program can determine 
whether or not a data base transaction was committed 
before the system failed. With this information 
available, the program can determine the point at 
which to resume a data base transaction. 

The application program "can perform a restart oper¬ 
ation only if the data administrator has defined 
both a transaction recovery file and a restart 
identifier file in the schema. 


PROCESSING OPERATIONS 

The following paragraghs describe the operations 
used for program restart if a system failure occurs: 

• Obtain a restart identifier 

Communicates with CDCS to obtain a restart 
identifier for the application program. 
The application program must save the 
restart identifier for subsequent use in a 
restart operation. If program restart 
capability is desired, this operation must 
be performed before the first data base 
transaction is begun. 


• Inquire about the status of the last data base 
transaction 

Communicates to CDCS a restart identifier 
and obtains from CDCS the transaction 
identifier for the last completed data base 
transaction associated with that restart 
identifier. CDCS then assigns the restart 
identifier obtained to the program. This 
operation provides for restarting an appli¬ 
cation program. Application program Logic 
then uses the transaction identifier to 
determine with which data base transaction 
to resume processing. The application 
program should contain the logic necessary 
to be restartable. 


Assigning a Restart Identifier 

To obtain the restart identifier assigned to this 
program by CDCS, you must use the ASSIGNID state¬ 
ment. The format is: 

ASSIGNID (restart-id C,ERR=s3) 

where 

restart-id = variable 

s = label of an executable statement 

to which control transfers on 
assign error 


A restart-id can be from 1 through 10 characters in 
length. A variable name must be used to specify a 
restart-id and must be defined as type CHARACTERS0. 

The restart identifier obtained by the ASSIGNID 
statement can then be used by the FINDTRAN state¬ 
ment; the program can then determine the status of 
a data base transaction when a system failure 
occurs. The restart identifier should not be saved 
on a data base file because it could be Lost if 
failure occurs. The application program should 
contain the logic necessary to save the identifier 
outside of the program. 

ASSIGNID should be specified before any updates are 
attempted within a data base transaction. ASSIGNID 
must not be specified within a data base trans¬ 
action. 


Performing a Restart Operation 

To obtain information for a program restart opera¬ 
tion after system failure, you must use the FINDTRAN 
statement. This statement is normally issued in 
the restart unit of the program. The format is: 

FINDTRAN (restart-id, tran-id C,ERR=s3> 
where 

restart-id = character constant or variable 

tran-id = variable 

s = Label of an executable statement 

to which control transfers on find 
error 

Restart-id identifies the 1- through 10-character 
restart identifier that was assigned to the program 
by the ASSIGNID statement before the system failure. 
If you use a character constant to specify restart- 
id, enclose the character string in apostrophes. 
If you use a variable name to specify restart-id, 
define the variable as type CHARACTER*10. 

Tran-id receives the transaction identifier of the 
last completed data base transaction; this identi¬ 
fier is returned only if the application program 
had begun a CDCS data base transaction prior to a 
system failure. The transaction identifier is not 
returned if no data base transaction has been 
committed for the specified restart identifier. A 
variable name must be used to specify tran-id and 
must be defined as type CHARACTER*10. 

Tran-id receives the characters ********** (10 

asterisks) if the restart identifier is unknown to 
CDCS. The restart identifier is unknown to CDCS if 
the wrong value is specified for restart-id or if 
the program terminated normally. If the program 
terminated normally, a new restart identifier must 
be obtained. 

Tran-id receives a value of 10 blanks if the re¬ 
start identifier is known to CDCS but no data base 
transaction had been completed prior to the system 
failure. The FINDTRAN statement executes normally, 
and a new restart identifier does not need to be 
obtained. The restart identifier specified as 
restart-id is reassigned to the program. 


• 3-18 


60483500 B 





If a transaction identifier is returned, a new 
restart identifier does not need to be obtained. 
The restart identifier specified as restart-id is 
reassigned to the program. 

In a program using sample sub-schema COMPARE (figure 
3-16), the ASSIGNID and FINDTRAN statements appear 
as shown in figure 3-25. This program is run 
interactively, and the user must enter one of the 
three options given. If the initial option is 
chosen, the ASSIGNID statement obtains the restart 


identifier assigned by CDCS. Include in the job 
stream the control statements needed to create a 
file to save the restart identifier in case a 
system failure occurs. If the restart option is 
chosen, the FINDTRAN statement is executed, and the 
program can determine the status of the data base 
transaction when the system failure occurred. The 
file containing the restart identifier must be 
attached in the job stream when the restart option 
is chosen. If the end option is chosen, program 
execution is terminated. 



PROGRAM RELMOD 
CHARACTER RESTID *10 
CHARACTER TRANID *10 
CHARACTER OPTION *7 
SUBSCHEMA (COMPARE) 

INVOKE 

0PEN(2,FILE='RESTART') 

10 PRINT*, 'ENTER: INITIAL, RESTART, OR END' 

READ*, OPTION 

IF (OPTION .EQ. 'INITIAL') THEN 
ASSIGNID (RESTID,ERR=50) 

WRITE(2,'(A10)') RESTID 
CLOSE(2) 

GO TO 25 

ELSE IF (OPTION .EQ. 'END') THEN 
GO TO 60 

ELSE IF (OPTION .EQ. 'RESTART') THEN 
READ(2,'(A10)') RESTID 
FINDTRAN (RESTID,TRANID,ERR=50) 

IF (TRANID .EQ. '**********•) THEN 

PRINT*, ' RESTART UNSUCCESSFUL OR UNNECESSARY' 
GO TO 60 

ELSE 


60 TERMINATE 
END 


Figure 3-25. Restarting a Data Base Transaction 
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ERROR PROCESSING AND STATUS 
HANDLING TECHNIQUES 


4 


DMS-170 offers a variety of error and status proc¬ 
essing mechanisms. Each serves a specific purpose 
in the operating environment- These mechanisms are 
summarized in table 4-1 and detailed in the follow¬ 
ing paragraphs. 

USING ERR AND END 
PROCESSING OPTIONS 

A transfer of control to special processing for 
error or end-of-file (EOF) conditions can be speci¬ 
fied in your program. This is accomplished by 
including the ERR and END options in the appropri¬ 
ate DHL statements. 

I The ERR option can appear in most statements, as 
shown in the formats in section 3. The END option 
can appear in the sequential READ statement. 


The formats for the ERR and END options are: 

ERR=statement-label 
END=statement-label 

When the ERR or END option is executed, control 
transfers to the statement identified by statement- 
label. The identified statement must be executable. 

Assume an input/output error occurred during execu¬ 
tion of the following statement: 

OPEN(FILEX,ERR=50) 

Execution of the OPEN statement is terminated, 
status is set to the appropriate error code as 
described later in this section, and program execu¬ 
tion continues at statement 50. 


TABLE 4-1. ERROR AND STATUS PROCESSING MECHANISMS 


Mechanism 

Definition 

Programmer Action 

Error 

processing 

option 

Syntax option that passes control to program 
logic on an error condition. Control is not 
passed when a CDCS relation condition indi¬ 
cating a null record occurrence or control 
break occurs. 

Include ERR option in appropriate DML 
statements. 

End-of-file 

processing 

option 

Syntax option that passes control to program 
logic on an EOF condition. 

Include END option in appropriate DML 
statements. 

Status block 

An array to which CDCS returns data base 
status information. 

Include the following operations in the pro¬ 
gram: establishing the data base status 
block, calling subroutine DMLDBST once, and 
testing the status block contents at appro¬ 
priate points. 

Constraint 

handling 

A method of avoiding situations in which 
constraints could be violated. 

Be aware of constraints, and follow the 
rules for modifying the files on which 
constraints have been imposed. 

Deadlock 

processing 

A method of recovering from a situation in 
which programs are contending for locked 
resources. 

If the program must have simultaneous locks 
on several resources, include a test for 
deadlock status and provide program logic 
to reestablish any released locks. 

Restart 

processing 

A method of allowing an application program 
to determine the point at which to begin 
processing following a system or program 
failure. 

Include the ASSIGNID statement and the 
FINDTRAN statement in the application pro¬ 
gram to determine the status of a data base 
transaction after a system or program 
failure occurs. 

Dropping a 
data base 
trans¬ 
action 

The capability to cancel a data base trans¬ 
action. 

Include the DROPTRAN statement in the appli¬ 
cation program. 
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Assume an EOF was sensed during execution of the 
following statement: 

READ(FILEX,END=75) 

Execution of the READ statement is terminated and 
execution continues at statement 75. 

Several examples of this type of error and end-of- 
file processing appear throughout section 3. 

ESTABLISHING A DATA 
BASE STATUS BLOCK 

An array called a data base status block can be 
established in your program to receive data base 
status information. When the status block is 
included in your program, CDCS updates the block 
after every operation on a realm or a relation. 


The minimum length of the data base status block is 
one word; the maximum length is 11 words. You can 
include some or all of the words for testing pur¬ 
poses. The content of the status block is shown in 
table 4-2. 


The following rules apply to the status block: 

• Only one status block can exist at a time in 
the program. 


• The status block must be declared as type 
INTEGER. 


• The length of the block must be sufficient to 
completely include each desired portion of 
status information. 


TABLE 4-2. STATUS BLOCK CONTENT 


Word 

Content 

Comments 

1 

The CDCS or CRM octal error code for the 
last data base operation on a realm or a 
relation. 

Only error codes are returned. Status codes indi¬ 
cating null occurrences or control breaks are not 
returned in this word. A zero value indicates no 
error occurred. Use 0 format for printing. 

2t 

A sub-schema item ordinal for CDCS errors 
occurring at the item level. 

Item-level errors are associated with data valida¬ 
tion and data base procedures established by the 
data administrator in the schema, and with CDCS 
record mapping. A zero value indicates no error 
occurred. Use I format for printing. 

3t 

A CRM octal code indicating file position 
of the realm when the last data base oper¬ 
ation was performed. The code is returned 
for open, close, read, and start opera¬ 
tions. For a relation operation, the code 
indicates the file position of the root 
realm. 

Code values are: 

01 g Beg inning-of-information. 

10 8 End-of-keylist. The last primary key value 

associated with a given alternate key was 
returned during a read operation using an 
alternate key value. 

20g End-of-record. A record was returned during 

a read operation. 

100 8 End-of-information. A sequential read 

operation was attempted after the previous 
operation returned the last record in the 
realm. 

Use 0 format for printing. 


The severity of an error that occurred 
during the Last data base operation. 

A zero value indicates no error occurred or a non- 
fatal error occurred. A value of one indicates a 
fatal error occurred. Use 0 or I format for print¬ 
ing. 

5 

The name of the function being performed 
when an error or relation condition oc¬ 
curred; the name is left-justified and 
blank filled. 

If no error has occurred, this word contains no 
valid information. Use A10 format for printing. 
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TABLE 4-2. STATUS BLOCK CONTENT (Contd) 


Word 

Content 

Comments 

6tt 

The rank of the realm on which a CDCS or 

CRM error occurred during a relation oper¬ 
ation. (The ranks of realms joined in a 
relation are numbered consecutively, with 
the root realm having rank 1.) 

A zero value indicates no error occurred. Use 

I format for printing. 

7 tT 

The lowest rank on which a control break 
occurred during a relation operation. 

All realms in the relation with a rank greater than 
the rank stored in this word also have control 
breaks or null status. (Null status overrides 
control break status.) A zero value indicates no 
control break occurred. Use I format for printing. 

stt 

The lowest rank for which there was a 
null record occurrence during a relation 
operation. 

ALL realms in the relation with a rank greater than 
the rank stored in this word also have null occur¬ 
rences. A zero value indicates no null occurrence. 
Use I format for printing. 

9,10,11 

The name of the realm on which an error 
occurred; the name is left-justified and 
blank filled. 

A blank value indicates no error occurred; a blank 
value also can indicate the error occurred on an 
operation not associated with input/output or 
occurred on an input/output operation not explic¬ 
itly requested by the application program. Use A30 
format for printing. 

fWords 2, 3, and 4 are treated as a single unit by CDCS; length must be provided for all three words if 
information for any portion of the unit is to be returned. 

tt 

Words 6, 7, and 8 must all be defined to obtain any one word of relation status information. 


The following declaration would provide a complete 
status block: 

INTEGER STATUS(11) 


• If DMLDBST is called more than once in a pro¬ 
gram, the status block defined in the last call 
is the one that is updated by CDCS. 


The following declaration would provide a 5-word 
status block reflecting all information except that 
pertaining to relation processing: 

INTEGER STATC5) 

The location and length of the status block are 
conveyed to CDCS through a call to the DMLDBST 
routine. The routine can be called at any point in 
the program after the INVOKE statement. The format 
of the call is: 

CALL DMLDBST(block-name,length) 
where 

block-name = name of the status block 
length = length in words of the status block 
The following rules apply to the DMLDBST routine: 

# The routine needs to be called one time only. 

• The call to DMLDBST should appear before the 
first DHL statement after INVOKE. Positioning 
of the DMLDBST call is important because the 
call initializes the status block to zeros and 
blanks. 


In a program using the sample sub-schema COMPARE 
shown in section 3, a data base status block decla¬ 
ration appears as shown in figure 4-1. The formats 
for printing the contents of the data base status 
block are also shown in the figure. 


PROGRAM DBSEXMP 
INTEGER STATBLK(II) 

SUBSCHEMA(COMPARE) 

INVOKE 

CALL DMLDBST(STATBLK,11) 

PRIVACY(CFILE,M0DE=I,PRIVACY=’XX99’) 
OPEN(REL3,M0DE=I,ERR=1G0) 

PFOFID= 1 MLN00840’ 

READ(REL3,ERR=6Q0,END=900) 


600 PRINT *, ’ERROR ON READ' 

PRINT 700, STATBLK 
700 FORMAT (IX, ’STATUS BLOCK* / 

1 1X,04,2X,I5,2X,03,2X,01,2X, 

1 A10,2X,I5,2X,I5,2X,I5,2X,A30) 

900 CLOSE(REL3) 

TERMINATE 

END 


I 


Figure 4-1. Establishing a Data Base 
Status Block 
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ERROR CHECKING 

Error checking should be performed after every 
operation on a realm or relation. Two methods are 
avaitable: 

# Test the error code in word 1 of the data base 

status block after every operation. For 

example: 

OPEN(CFILE) 

IF(STATBLKO) .NE. 0)... 

• Include the ERR option on the DML statement as 

appropriate and handle status block printing in 
one specific section of the program. For 

example: 

0PEN(CFILE,ERR=50) 


AVOIDING CONSTRAINT 
VIOLATIONS 

The data administrator incorporates constraints in 
the schema for the purpose of protecting interde¬ 
pendent data. Constraints can be defined for two 
logically associated items within a single file 
(single-file constraint) and for two logically 
associated items within two files (two-file con¬ 
straint) . 

Consider an employment file in which each record 
occurrence contains an employee number and a man¬ 
ager number, where the manager number conforms to 
the structure of the employee number. Figure 4-2 | 
illustrates this concept. Assume, for example, the 
data administrator designed the schema with the 
following single-file constraint: 

MNGR-NO DEPENDS ON EMP-NO 


50 PRINT 60,$TATBLK 


STATUS CHECKING 

Status checking should be performed as appropriate 
during relation processing to determine control 
breaks and null occurrences. Testing is performed 
on words 7 and 8, respectively, of the data base 
status block. (For more information about control 
break and null occurrence, see section 3.) 

Word 7 indicates the lowest rank on which a control 
break occurred. A nonzero value in this word 
indicates a control break. To test for a control 
break, you can include a test on word 7 in your 
program. For example: 

READ(CFILE) 

IF(STATBLK(7) .NE. 0)... 


In this example, MNGR-NO (the dependent item) is 
dependent upon EMP-NO (the dominant item). This 
means that no occurrence of the dependent record 
can exist in the data base unless an occurrence of 
the dominant record also exists with the same value 
of the associated data item. Also, no dominant 
record can be deleted if a dependent record exists 
with the same value of the associated data item. 

The dominant item in a single-file constraint is 
always a primary key or an alternate key with no 
duplicates; the dependent item is a primary key or 
an alternate key, and the alternate key can have 
duplicates. You would violate the constraint pre¬ 
sented in the example if you attempted to do any of 
the following: 

* Store an employee EMPLOYMENT record if an 
EMPLOYMENT record for the referenced manager 
does not exist. (An organization could not 
recognize a manager who was not first an em¬ 
ployee.) 


I 


Word 8 indicates the lowest rank for which there 
was a null occurrence. A nonzero value in this 
word indicates a null occurrence. Since the right 
bracket character ( 1 ) is stored in a null record, 
you would probably want your program to bypass 
printing or move spaces to the print line. To test 
for a null occurrence, you can include a test on 
word 8 in your program. For example: 

READ(CFILE) 

IF(STATBLK(8) .NE. 0)... 


• Change the value of the dominant item (EMP-NO) I 
if a corresponding dependent item (MNGR-NO) I 
exists. (An organization could not change an 
employee number as long as references to the 
old number existed.) 

• Delete a manager EMPLOYMENT record if an em¬ 
ployee EMPLOYMENT record with the corresponding 
manager number exists. (An organization could 
not remove a manager while an employee was 
still reporting to that individual.) 


Manager EMPLOYMENT Record 


Employee EMPLOYMENT Record 



Figure 4-2. Single-File Constraint Example 
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In a single-file constraint, at least one record 
| exists that has no dominant record. This situation 
occurs in the single-file constraint example for 
the employee who has no manager. The record for 
this employee must have the same value for both 
EMP-NO and MNGR-NO. 

If you are creating a file on which a single-file 
constraint has been imposed, take the following 
steps in the order given: 


1. Create the file with record occurrences of the 
| items that have no dominant record. 

2. Close the file. 

3. Reopen the file for input/output and add the 

I record occurrences of the dependent items. 
(Ensure that a dominant record occurrence 
exists before adding any corresponding depen¬ 
dent item.) 

For a situation involving a two-file constraint, 
consider a course file and a curriculum file. 

Assume that the data administrator designed the 
schema with the following two-file constraint: 

COURSE-ID OF CURR-REC DEPENDS ON 
COURSE-ID OF COURSE-REC 

The records of the two files and the data items 

associated in the constraint are shown in figure 
4-3. CURR-REC (the dependent record) is dependent 
upon COURSE-REC (the dominant record) if there is a 
correspondence between them. A correspondence 
exists if the dependent record and the dominant 
record each contain the same value for the common 

item, which is COURSE-ID in this example. 

You would violate the constraint presented in the 
two-file constraint example if you attempted to do 
any of the following: 

• Delete a COURSE-REC occurrence if a correspond¬ 
ing CURR-REC occurrence exists. (The university 
could not drop a course from its curriculum 

while a student was still enrolled.) 

• Change the COURSE-ID value of a COURSE-REC 
occurrence if a corresponding CURR-REC occur¬ 
rence exists. (The university could not change 
the identification code of a course as long as 
a student's record still uses that code.) 


• Add a CURR-REC occurrence if a corresponding 
COURSE-REC occurrence does not exist. (A stu¬ 
dent could not be enrolled in a course that was 
not being offered by the university.) 


If you are modifying the common item of a file on 
which a two-file constraint has been imposed and 
the common item is a primary key, take the follow¬ 
ing steps in the order given: 

1. Write the dominant record with the new value in 
the common item. 

2. Read a dependent record, and change the value 
of the common item to the new value of the dom¬ 
inant record. Rewrite the dependent record. 
(Perform this step for each dependent record of 
the dominant record.) 

3. Delete the dominant record with the old value. 


If you are modifying the common item of a file on 
which a two-file constraint has been imposed and 
the common item is an alternate key, take the fol¬ 
lowing steps in the order given: 

1. Write each dependent record containing the old | 
value of the item to a temporary file. 

2. Delete each dependent record containing the old | 
value of the item from the data base. 

3. Read the dominant record, and change the value 
of the data item to the new value. Rewrite the 
dominant record. 

4. Read a dependent record from the temporary 
file, and change the value of the common item 
to the new value of the dominant record. Write 
the dependent record to the data base. (Per¬ 
form this step for each dependent record of the 
dominant record.) 


Since constraints are established in the schema and 
not indicated in any way in the sub-schema, it is 
the responsibility of the data administrator to 
supply you with this information. By being aware 
of constraints, you can anticipate violations and 
prevent them from occurring in your application 
program. 


COURSE-REC 
(Course File) 


CURR-REC 

(Curriculum File) 



Figure 4-3. Two-File Constraint Example 
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When a constraint is violated, CDCS aborts the 
particular operation, returns a nonfatal 601g 
error code, and continues processing. The error 
message identifies the record on which the attempted 
violation occurred. Whenever you are writing, 
deleting, or rewriting a record, the appropriate 
data base status block entry should be tested. 

Two general rules to remember for constraint proc¬ 
essing are: 

• Always delete a dependent record occurrence 
before deleting the dominant record occurrence. 

• Always write the dominant record occurrence 
before writing a dependent record occurrence. 


ANTICIPATING DEADLOCK 
SITUATIONS 

CDCS allows concurrent access to a data base. This 
means that two or more application programs can 
access the same file (realm) at the same time. The 
following can take place: 

• Two or more application programs can open the 
same fi le for input and perform simultaneous 
read operations. 

• One application program can open a file for 
input/output and perform update operations, 
while other programs can open the same file for 
input and perform simultaneous read operations. 

• Two or more application programs can open the 
same file for input/output, but only one pro¬ 
gram can gain immediate access to a particular 
record to perform update operations. 


The integrity of the data base is maintained through 
CDCS locking mechanisms: the record locking mecha¬ 
nism and the file locking mechanism. CDCS holds a 
| lock (either protected or exclusive) for an appli¬ 
cation program and prevents update of the locked 
file or record by any other program. 


Exclusive locking prohibits read and update opera¬ 
tions on the realm. Protected locking prohibits 
only update operations (allows read operations). 
See the CDCS 2 Application Programming reference 
manual for detailed information about locking. 


Whenever two or more application programs contend 
for locked resources, which are files or records, a 
deadlock situation can occur. Contention occurs 
when two programs, each having at least one resource 
locked, attempt to lock a resource that is locked 
by the other program. Neither program can continue 
processing, because neither program can obtain the 
necessary locks. CDCS automatically releases the 
locked resources of one program. The other program 
then can obtain the locks it requires and can 
continue processing. 

When CDCS has detected a deadlock situation and has 
released the locked resources of an application 
program, CDCS issues the deadlock error status code 
663g to that program. If the application program 
established the data base status block, the program 
can check the first word for the deadlock code. 

If your program must have locks on several re¬ 
sources, your program should always test for dead¬ 
lock status before attempting to update a file. If 
deadlock occurs, your program should reestablish 
the locks that it held before continuing further 
processing. 

An example illustrating deadlock processing appears 
in figure 4-4. Files joined in relation REL3 are | 
opened for input/output. The program presumably is 
reading a record prior to update and CDCS has 
locked all records in the relation occurrence. The 
example includes a test of word 1 in the status 
block to enter a loop in case of deadlock. In the 
loop, the program attempts to reestablish the locks 
and checks for deadlock. 


PROGRAM DEADLCK 
INTEGER STATBLK(II) 

SUBSCHEMA(COMPARE) 

INVOKE 

CALL DMLDBST(STATBLK,11) 

PRIVACY(CFILE,PRIVACY=*XX99 1 ) 
0PEN(REL3,ERR=1G0) 

PR0FID='JMS00160' 

30 READ(REL3,KEY=PR0FID) 

IF(STATBLKO) .EQ. 0"663") GO TO 30 


900 CLOSE(REL3) 
TERMINATE 
END 


Figure 4-4. Deadlock Processing | 


4-6 


60483500 B 




TABLE 4-3. LOCKING OPERATIONS 


Operation 

Effect 

An application program opens a realm for input/output 
and includes a DML LOCK statement. (This should be 
avoided whenever possible. 

CDCS locks the entire realm against update by other 
users. An unlock or close operation by that pro¬ 
gram releases the lock. 

An application program opens a realm for input/output 
without including a DML LOCK statement. 

CDCS locks the record on the read operation. A 
rewrite, delete, or another read operation by that 
program releases the lock. 

An application program opens a realm for output with¬ 
out including a DML LOCK statement. 

CDCS locks the entire realm. A close operation by 
that program releases the lock. 

An application program opens a relation for 
input/output. 

CDCS locks all records in a given relation occur¬ 
rence. A rewrite or delete operation by the pro¬ 
gram releases the lock on the record updated. The 
next relation read operation by that program re¬ 
leases the record locks on the files for which a 
new record has been read. 


Whenever two or more application programs contend 
for locked resources, which are files or records, a 
deadlock situation can occur. Contention occurs 
when two programs, each having at least one 
resource locked, attempt to lock a resource that is 
locked by the other program. Neither program can 
continue processing, because neither program can 
obtain the necessary locks. CDCS automatically 
releases the locked resources of one program. The 
other program then can obtain the locks it requires 
and can continue processing. 

When CDCS has detected a deadlock situation and has 
released the locked resources of an application 
program, CDCS issues the deadlock error status code 
663g to that program. If the application program 
established the data base status block, the program 
can check the first word for the deadlock code. 

If your program must have locks on several 
resources, your program should always test for 
deadlock status before attempting to update a 
file. If deadlock occurs, your program should 
reestablish the locks that it held before 
continuing further processing. 

An example illustrating deadlock processing appears 
in figure 4-5. Files joined in relation REL3 are 


PROGRAM DEADLCK 
INTEGER STATBLKC11) 

SUBSCHEMA(COMPARE) 

INVOKE 

CALL DMLDBST(STATBLK,!1) 

PRIVACY (CFILE^RIVACY^'XX?? 1 ) 
0PEN(REL3,ERR=10Q) 

PROFID=*JMS00160' 

30 READ(REL3,KEY=PR0FID) 

IF(STATBLK(1) -EQ. 0"663") GO TO 30 


900 CLOSE(REL3) 
TERMINATE 
END 


Figure 4-5. Deadlock Processing 

opened for input/output. The program presumably is 
reading a record prior to update and CDCS has 
locked all records in the relation occurrence. The 
example includes a test of word 1 in the status 
block to enter a Loop in case of deadlock. In the 
Loop, the program attempts to reestablish the locks 
and checks for deadlock. 
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DEVELOPING FORTRAN PROGRAMS 


5 


FORTRAN application programming in the DMS-170 
environment relieves you of several responsi¬ 
bilities. For example: 

• You do not have to describe data within your 

program; the data administrator incorporates 
data descriptions in the schema and sub-schema. 
Data descriptions in a sub-schema are included 
in your program. 

• You do not have to write conversion routines; 

CDCS handles all conversion for you. 

• You do not have to write all routines that 

perform validity checking; the data administra¬ 
tor generates data base procedures, which are 
specified in the schema and called at 
appropriate times. 

• You do not have to write separate logging and 

recovery utilities; the data administrator 
provides for data base restoration by specify¬ 
ing logging operations in the master directory. 

• You do not have to be concerned with the details 
of input/output; CDCS handles them. 

DEVELOPING AN APPLICATION 
PROGRAM 

To develop a DMS-170 application program, you must 
do the following: 

• Obtain a listing of the sub-schema from the 

data administrator. 

• Obtain the name of the sub-schema library from 
the data administrator. 

• Obtain the appropriate privacy keys from the 

data administator. 

• Be aware of any constraints that have been 

incorporated in the schema. 

• Include appropriate DML statements in your 

FORTRAN program. 

I « Obtain information on whether data base trans¬ 
actions can or should be used. 


COMPILING AND EXECUTING 
THE SOURCE PROGRAM 

To compile and execute a DMS-170 FORTRAN applica¬ 
tion program, you must do the following: 

1. Attach the sub-schema library for DML preproc¬ 
essing of the source program. 

2. Include a DML control statement for DML pre¬ 
processing of the source program. 

3. Include an FTN5 control statement that speci¬ 
fies the DML output file as the input file for 
the FORTRAN 5 compiler. 

4. Include an LDSET control statement for loading 
the system library for execution of the source 
program. 

5. Include the name of the file containing the 
relocatable binary program CLGO is the default 
name) to execute the program. 

6. Be sure that CDCS is active or use CDCSBTF I 
under the direction of the data administrator. | 

DML statements are preprocessed before source 
program compilation. The DML preprocessor tran¬ 
slates the DML statements into appropriate FORTRAN 
statements. When translation is complete, the DML 
preprocessor writes the FORTRAN source program to 
an output file with the default name DMLOUT. This 
output file, complete with translated DML state¬ 
ments, becomes the input file to the FORTRAN com¬ 
piler. A block diagram illustrating FORTRAN/DML 
preprocessing is shown in figure 5-1. 

The DML control statement calls the DML preproc¬ 
essor. A list of DML control statement parameters 
is shown in figure 5-2. 

The statements required to execute the DML preproc¬ 
essor and to compile the source program are shown 
in figure 5-3. 

The statements required to execute the DML preproc¬ 
essor and to compile and execute the source program 
are shown in figure 5-4. An LDSET control state¬ 
ment naming the system library, DMSLIB, must be 
included for program execution. 



Figure 5-1. FORTRAN DML Preprocessing 
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OWL (pi,p2,p3,p4,p5,p6,p7) 


pi 

SB=lfn 

Name of file containing sub-schema 
library. 

T Trivial. The syntax of the usage 
is correct, but it is questionable. 


SB 

Same as SB=SBLFN. 

W Warning. The syntax is incorrect, 
but the processor has been able to 


S8=0 

omitted 

Not allowed. 

Same as SB=S8LFN. 

recover by making an assumption 
about what was intended. 

F Fatal. An error prevents DML from 

p2 

LV=F5 

Specifies FORTRAN 5. 

processing the statement in which 
it occurs. Unresolvable semantic 


LV 

Same as LV=F5. 

errors also fall into this 
category. Processing continues 


omitted 

Dependent on installation. 

with the next statement. 

p3 

I=lfn 

Name of file containing FORTRAN 
source program with added DHL 
statements to be preprocessed by DML. 

C Catastrophic. Compilation cannot 
continue; however, DML advances to 
the end of the current program 
unit and attempts to process the 


I 

Same as I=C0MPILE. 

next program unit. 


omitted 

Same as I=INPUT. 

ET Same as ET=F. 


1=0 

Not allowed. 

omitted Same as ET=0. 

p4 

0=1 fn 

Name of file to which translated 
version of FORTRAN source program is 
to be written. DML statements 
appearing in FORTRAN program are 
translated into FORTRAN statements 
before being written to this file. 

ET=0 The job step is not to be aborted 

even if errors occur (except for 
control statement errors). 

T and W errors do not invalidate the output 
file produced by DML (the file specified by 
the 0 option). The translated code on the 


0 

Same as 0=DML0UT. 

file can still be compiled (barring any errors 
not related to DML), but the results might not 


omitted 

Same as 0=DML0UT. 

be what the user intended. F and C errors, 
however, produce an output file that cannot be 


0=0 

No output is produced. 

successfully compiled by FORTRAN. 

P5 

E=tfn 

Name of file to which error 
diagnostics are to be written. 

p7 DS Directive suppression. Listing 

control directives are not generated; 
all FORTRAN statements generated by 


E 

omitted 

Same as E=ERRS. 

Same as E=0UTPUT. 

DML preprocessing appear in the 

FORTRAN source listing. 

omitted Listing control directives are 

p6 

ET=op 

Error termination code. Four levels 
of errors are defined; if an error of 
the specified level or higher takes 
place/ the job is aborted to an 

EXIT(S) control statement (NOS/BE) or 
EXIT control statement (NOS). The 
abort does not take place until DML 
is finished. The possible values for 
op, in increasing order of severity, 
are as follows: 

generated; FORTRAN statements 
generated by DML preprocessing of the 
SUBSCHEMA and INVOKE statements do 
not appear in the FORTRAN source 
listing. 

FORTRAN CALL statements generated as a result 
of executable DML statements always appear on 
the FORTRAN source listing regardless of DS 
specification. 


Figure 5-2. DHL Control Statement 
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I 


Job statement 

USER statement ) _ 

CHARGE statement/"^ 

ATTACH(sub-schema-library) 

DML(SB=sub-schema-library,LV=F5) 

FTN5(I=DML0UT) 


NOS only 


End-of-record 

FORTRAN source program containing DML statements 
E nd-of-info rmation 


Figure 5-3. Executing DML and Compiling 
the Source Program 


I 


Job statement 

USER statement > ^_ 

CHARGE statement / 

ATTACH(sub-schema-library) 

DML($B=sub-schema-library,LV=F5) 

FTN5(I=DML0UT) 

LDSET(LIB=DM$LIB) 

LGO. 


NOS only 


End-of-record 

FORTRAN source program containing DML statements 
End-of-information 


Figure 5-4. Compiling and Executing 
the Source Program 


SAMPLE PROGRAMS 


appear in the FORTRAN source listing. When the DS 
parameter is omitted, listing control statements 
are generated and inserted immediately after the 
SUBSCHEMA and INVOKE statements; therefore, the 
FORTRAN statements generated by DML preprocessing 
of these statements do not appear in the FORTRAN 
source listing. 

Listing control directives appear in the sample 
program source listings in the following form: 

C$ LIST(ALL=0) 

CS LIST(ALL) 


These directives are generated automatically by the 
DML preprocessor. They appear because the DS 
parameter in each DML control statement was omitted. 
Notice, however, that CALL statements generated as 
a result of executable DML statements appear re¬ 
gardless of the DS parameter setting. 


Each sample program is illustrated by including the 
control statements, the source program statements, 
the compilation listing, and the output of program 
execution. The programs are: 

Program RATING Figure 5-5 

Program INDAVGE Figure 5-6 


Program RELATE 
Program CHARGES 
Program ADMIT 


Figure 5-7 
Figure 5-8 
Figure 5-9 


Program TRANPRG 


Figure 5-10 


Sample programs appear in the remainder of this 
section. Each program uses the data base environ¬ 
ment that is established and illustrated in appen¬ 
dix C. You should read this appendix to become 
familiar with the schema, sub-schemas, and stored 
data before examining the FORTRAN programs. 


When the DML preprocessor translates DML statements 
into FORTRAN statements, the FORTRAN statements can 
be printed out or suppressed, depending on the 
setting of the DS parameter on the DML control 
statement. When the DS parameter is included, all 
FORTRAN statements generated by the DML preprocessor 


Program TRANPRG, shown in figure 5-10, is an inter¬ 
active job. The file description and input file 
for this program appear as shown in figure 5-11. 

The figures show the sample programs (listed above) 
being executed when CDCS is active at system con¬ 
trol point. CDCS Batch Test Facility (CDCSBTF) can 
also be used. When using CDCSBTF, replace the 
LDSET and the LGO control statements with the fol¬ 
lowing control statements: 

LIBRARY,DMSLIB. 

CDCSBTF (LGO/MDPFN=MSTRDIR,lfN=xx) 
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Control Statements for Interactive Job 


ATTACH(FTNRUN) 

ATTACH(SSLIB) 

DHL(SB=SSLIB,LV=F5,I=FTNRUN) 
FTN5(I=DML0UT) 

ATTACH(INTRAN) 

FILE (INTRAN,RT=Z,BT=C) 

LDSET(LIB=DHSLIB) 

LGO. 

End-of-record 


Source Program 

PROGRAM TRANPRG 
C 

C THIS PROGRAM DEMONSTRATES THE USE OF TRANSACTIONS AND 
C PROGRAM RESTART. FIRST THE PROGRAM DETERMINES IF THE 
C RUN IS AN INITIAL RUN OR A RESTART OPERATION BY 
C REQUESTING INPUT FROM A TERMINAL. 

C 

C THEN THE PROGRAM READS TRANSACTIONS FROM FILE INTRAN 
C (SHOWN IN FIGURE 5-11), BEGINS TRANSACTION 

C PROCESSING, AND UPDATES TWO REALMS: SFILE AND CFILE. 

C 

C DURING RESTART PROCESSING, THE PROGRAM POSITIONS FILE 
C INTRAN BY READING AND DISCARDING RECORDS THAT WERE 
C SUCCESSFULLY PROCESSED BEFORE THE FAILURE. 

C 

INTEGER STATBLXOI) 

CHARACTER RESTID *10 
CHARACTER TRANID *10 
CHARACTER INID *10 
CHARACTER INSTID *11 
CHARACTER INMJR *20 
CHARACTER OPTION *7 
SUBSCHEMA (RELATION) 

DATA TRANID/'0000000000*/ 

INVOKE 

CALL DMLDBST (STATBLK,11) 

OPEN <5,FILE='INTRAN',STATUS='OLD',ACCESS='SEQUENTIAL•) 
OPEN(2,FILE='RESTART') 

10 PRINT*, ' ENTER: INITIAL, RESTART, OR END' 

READ*, OPTION 

IF (OPTION .EQ. 'INITIAL') THEN 
ASSIGNID (RESTID,ERR=50) 

WRITE(2,'(A10)') RESTID 
CLOSE (2) 

GO TO 25 

ELSE IF (OPTION .EQ. 'RESTART') THEN 
READ(2,'(A10)') RESTID 
F1NDTRAN (RESTID,TRANID,ERR=50) 

IF (TRANID .EQ. •**********') THEN 

PRINT*, ' RESTART UNSUCCESSFUL OR UNNECESSARY 
GO TO 60 

ELSE 

15 READ (5,*,ERR=60,END=60) IN ID, INSTID, INMJR, NUM 

DO 20 I1=1,NUM 

20 READ (5,*,ERR=60,END=60) IDENT,COURS,GRADE, 

1 CODE,DATE,UNITS 

IF (INID .EQ. TRANID) THEN 
GO TO 25 

ELSE 

GO TO 15 
END IF 
END IF 


Figure 5-10. Program TRANPRG (Sheet 1 of 5) 
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ELSE IF (OPTION .EQ. 'END') THEN 
GO TO 60 

ELSE 

GO TO 10 
END IF 
C 

C BEGIN DATA BASE PROCESSING 
C 

25 PRIVACY (CFILE,PRIVACY='XX99’> 

OPEN (SFILE,K0DE=I0,ERR=50) 

OPEN (CFILE,H0DE=I0,ERR=50) 

C 

C MAIN LOOP BEGINS. THIS READS AND PROCESSES FILE INTRAN. 
C 

DO 35 JJ=1,9999 

READ (5,*,ERR=45,END=55) TRANID, INSTID,INMJR,NUM 
BEGINTRAN (TRANID,ERR=45) 

STID=INSTID 

READ (SFILE,KEY=STID,ERR=45) 

INMJR=MAJOR 

REWRITE (SFILE,ERR=45) 

CSTID=STID 
DO 30, 11=1,NUM 

READ (5,*,ERR=45,END=45) IDENT,COURS,GRADE, 

1 CODE,DATE,UNITS 

30 WRITE (CFILE,ERR=45) 

35 COMMITTRAN (ERR=45) 

C 

C MAIN LOOP ENDS. 

C 

45 PRINT*, ' TRANSACTION ERROR, TRANID = ', TRANID 
50 PRINT 98, STATBLK(1),STATBLK(2),STAT8LK(3) 

DROPTRAN 

55 PRINT*, 'DATA BASE PROCESSING COMPLETED' 

CLOSE (SFILE) 

CLOSE (CFILE) 

60 TERMINATE 

CLOSE (5,STATUS='DELETE') 

90 FORMAT (A10,A11,A20,I1> 

92 FORMAT (A14,A6,F3.1,A1,A8,I1) 

98 FORMAT (IX,'STATUS BLOCK'/1X,04,2X,I5,2X,A10> 

END 

End-of-Record 


Compilation Listing 


PROGRAM TRANPRG 74/74 0PT=0 


1 PROGRAM TRANPRG 

2 C 

3 C THIS PROGRAM DEMONSTRATES THE USE OF TRANSACTIONS AND 

4 C PROGRAM RESTART. FIRST THE PROGRAM DETERMINES IF THE 

5 C RUN IS AN INITIAL RUN OR A RESTART OPERATION BY 

6 C REQUESTING INPUT FROM A TERMINAL. 

7 C 

8 C THEN THE PROGRAM READS TRANSACTIONS FROM FILE INTRAN 

9 C (SHOWN IN THE PRECEDING FIGURE), BEGINS TRANSACTION 

10 C PROCESSING, AND UPDATES TWO REALMS: SFILE AND CFILE. 

11 C 

12 C DURING RESTART PROCESSING, THE PROGRAM POSITIONS FILE 

13 C INTRAN BY READING AND DISGARDING RECORDS THAT WERE 

14 C SUCCESSFULLY PROCESSED BEFORE THE FAILURE. 

15 C 


Figure 5-10. Program TRANPRG (Sheet 2 of 5) 



16 

INTEGER STA1BLKC11) 


17 

CHARACTER RESTID *10 


18 

CHARACTER TRANID *10 


19 

CHARACTER IN ID *10 


20 

CHARACTER INSTID *11 


21 

CHARACTER INMJR *20 


22 

CHARACTER OPTION *7 


23 ** 

SUBSCHEMA (RELATION) 


24 C$ 

LIST (ALL=0) 


112 CS 

LIST(ALL) 


113 

DATA TRANID/'0000000000'/ 


114 ** 

INVOKE 


115 C$ 

LIST(ALL=0) 


125 CS 

LIST (ALL) 


126 

CALL DMLINV(0002,DBF 0001, 10HRELATION ,10H 


127 

+10H ,0"76710464332261536703") 


128 

CALL DMLDBST (STATBLK-11) 


129 

OPEN(5,FILE=‘INTRAN',STATUS='OLD * / ACCESS='SEQUENTIAL') 

130 

OPEN (2,FILE='RESTART') 


131 10 

PRINT*, ' ENTER: INITIAL, RESTART, OR END' 


132 

READ*, OPTION 


133 

IF (OPTION .EQ_ 'INITIAL') THEN 


134 ** 

ASSIGNID (RESTID,ERR=50) 


135 

CALL DMLGTID(RESTID ,*50 ) 


136 

WRITE (2,'(A10)') RESTID 


137 

CLOSE(2) 


138 

GO TO 25 


139 

ELSE IF (OPTION .EQ. 'RESTART') THEN 


140 

READ(2,'(A10)') RESTID 


141 ** 

FINDTRAN (RESTID,TRANID,ERR=50) 


142 

CALL DMLFIND(RESTID ,TRANID ,*50 ) 


143 

IF (TRANID .EQ. ’**********') THEN 


144 

PRINT*, ' RESTART UNSUCCESSFUL OR 

UNNECESSARY' 

145 

GO TO 60 


146 

ELSE 


147 15 

READ (5,*,ERR=60,END=60) INID,INSTID,INMJR,NUM 

148 

DO 20 I1=1,HUM 


149 20 

READ (5,*,ERR=60,END=60) IDENT,COURS,GRADE, 

150 

X CODE,DATE,UNITS 

151 

IF (INID .EQ. TRANID) THEN 


152 

GO TO 25 


153 

ELSE 


154 

GO TO 15 


155 

END IF 


156 

END IF 


157 

ELSE IF (OPTION .EQ. 'END') THEN 


158 

GO TO 60 


159 

ELSE 


160 

GO TO 10 


161 

END IF 


162 C 



163 C 

BEGIN DATA BASE PROCESSING 


164 C 



165 ** 

PRIVACY (CFILE,PRIVACY='XX99') 


166 25 

CALL DMLPRV(1,1,0,0002, 


167 

+0"60","XX99 '•/• V 

”> 

168 ** 

OPEN (SFILE,M0DE=I0,ERR=50) 


169 

CALL DNLOPN(DBF0001,0001,2HIO,*50 > 


170 ** 

OPEN (CFILE,M0DE=I0,ERR=50) 


171 C 

* 


172 C 

MAIN LOOP BEGINS. THIS READS AND PROCESSES 

FILE INTRAN. 

173 C 



174 

CALL DMLOPN(DBF0002,0002,2HIO,*50 ) 


175 

DO 35 JJ=1,9999 


176 

READ (5,*,ERR=45,END=55) TRANID, INSTID,INMJR,NUM 

177 ** 

BEGINTRAN (TRANID,ERR=45) 


178 

CALL DMLBEG(TRANID ,*45 ) 


179 

STID=INSTID 


180 ** 

READ (SFILE,KEY=STID,ERR=45) 


181 

CALL DMLRDK(DBF0001,0001,00001,0001,1,0011, 

0,0000,00, 

182 

+STID ,*45 ) 



Figure 5-10. Program TRANPRG (Sheet 3 of 5) 


60483500 B 



183 


184 

★* 

185 


186 


187 


188 


189 


190 

** 

191 

30 

192 

** 

193 

C 

194 

c 

195 

c 

196 

35 

197 

45 

198 

50 

199 

** 

200 


201 

55 

202 

★* 

203 


204 

** 

205 


2Q6 

** 

207 

60 

208 


209 

90 

210 

92 

211 

98 

212 



INMJR=MAJOR 

REWRITE (SFILE / ERR=45) 

CALL DMLR EW(DBF0001,0,0001,00001,*45 ) 

C$TID=STID 

DO 30, 11=1,NUM 

READ (5,*,ERR=45,END=45) IDENT,C0URS,6RADE, 

X CODE,DATE,UNITS 

WRITE (CFILE,ERR=45) 

CALL DMLWRT(DBF0002,0,0002,00001 ,*45 ) 

COMMITTRAN (ERR =45) 

MAIN LOOP ENDS. 

CALL DMLCMT (*45 ) 

PRINT*, ' TRANSACTION ERROR, TRANID = ', TRANID 
PRINT 98, STATBLK (1) ,STATBLK (2) ,STATBLK (3) 
DROPTRAN 
CALL DNLDRP 

PRINT*, 'DATA BASE PROCESSING COMPLETED' 

CLOSE (SFILE) 

CALL DMLCLS (DBF0001,0001) 

CLOSE (CFILE) 

CALL DMLCLS<DBF0002,0002> 

TERMINATE 
CALL DMLEND 

CLOSE (5,STATUS=‘DELETE') 

FORMAT (A10,A11,A20,I1) 

FORMAT (A14,A6,F3.1,A1,A8,I1) 

FORMAT (IX,'STATUS BLOCK' /1X,04,2X,I5,2X,A10) 
END 


—VARIABLE MAP—(LO=A) 


-NAME-ADDRESS- 

■BLOCK- 

-PROPERTIES- 

-TYPE- 

CODE 

OB 

/DQ002AB/ 


CHAR*1 

COURS 

2B 

/DB0002/ 


CHAR*6 

CSTID 

IB 

/D&0002/ 


CHAR*11 

DATE 

OB 

/D0002AB/ 


CHAR*8 

DBA0001 

706B 



INTEGER 

DBF0001 

16B 

/DBOOQO/ 


INTEGER 

DBF0002 

67B 

/DBQQQO/ 


INTEGER 

DBI0001 

OB 

/DBQQ01/ 

EQV 

CHAR*1 

DB10002 

OB 

/DB0002/ 

EQV 

CHAR*1 

DBN0001 

134B 

/DBOOOO/ 


INTEGER 

DBREALM 

OB 

/DBOOOO/ 


INTEGER 

DBRELST 

10B 

/DBOOOO/ 


INTEGER 

DBRUID 

7B 

/DBOOOO/ 


INTEGER 

DBR0001 

12B 

/DBOOOO/ 


INTEGER 

DBR0002 

63B 

/DBOOOO/ 


INTEGER 

DBSCNAM 

4B 

/DBOOOO/ 


INTEGER 

DBSTAT 

3B 

/DBOOOO/ 


INTEGER 

DBS0001 

15B 

/DBOOOO/ 


INTEGER 

DBSQ002 

66B 

/DBOOOO/ 


INTEGER 

DBT0001 

61B 

/DBOOOO/ 


INTEGER 

DBTQ002 

132B 

/DBOOOO/ 


INTEGER 

GRADE 

OB 

/D0Q02AA/ 


REAL 

I DENT 

OB 

/DB0002/ 

EQV 

CHAR *14 

II 

712B 



INTEGER 

INID 

700B 



CHAR *10 

INMJR 

703B 



CHAR*20 

INSTID 

701B 



CHAR*11 

JJ 

714B 



INTEGER 

MAJOR 

IB 

/DB0001/ 


CHAR*20 

NUM 

71 IB 



INTEGER 

OPTION 

70 5B 



CHAR*7 

RESTID 

676B 



CHAR*10 

STATBLK 

663B 



INTEGER 

STID 

OB 

/DB0001/ 

EQV 

CHAR*11 

TRANID 

677B 



CHAR *10 

UNITS 

OB 

/D0002AC/ 


INTEGER 


SIZE 


3 

35 

35 


2 

2 


11 


Figure 5-10. Program TRANPRG (Sheet 4 of 5) 
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—PROCEDURES— CL0=A) 

-NAME-TYPE-ARGS— 

-CLASS- 

DMLBEG 2 

SUBROUTINE 

DMLCLS 2 

SUBROUTINE 

DMLCMT 1 

SUBROUTINE 

OMLDBST 2 

SUBROUTINE 

DMLDRP 0 

SUBROUTINE 

DMLEND 0 

SUBROUTINE 

DMLFIND 3 

SUBROUTINE 

DMLGTID 2 

SUBROUTINE 

DMLINV 6 

SUBROUTINE 

DMLOPN 4 

SUBROUTINE 

DMLPRV 8 

SUBROUTINE 

DMLRDK 11 

SUBROUTINE 

DMLREVI 5 

SUBROUTINE 

DMLWRT 5 

SUBROUTINE 

LOCF GENERIC 1 

INTRINSIC 

—STATEMENT LABELS—<L0=A) 

-LABEL-ADDRESS-PROPERTIES-DEF 

10 46B 

131 

15 112B 

147 

20 INACTIVE DO-TERM 

149 

25 146B 

166 

30 INACTIVE DO-TERM 

191 

35 INACTIVE DO-TERM 

196 

45 255B 

197 

50 257B 

198 

55 263B 

201 

60 271B 

207 

90 345B FORMAT 

209 

92 3508 FORMAT 

210 

98 354B FORMAT 

211 

' —ENTRY POINTS—(LO=A) 

-NAME-ADDRESS—ARGS- 

TRANPRG 5B 0 


—I/O UNITS—(LO=A) 

-NAME- PROPERTIES- 

— 

TAPE2 AUX/FMT/SES 

TAPES AUX/FMT/SEQ 

—STATISTICS— 

PROGRAM-UNIT LENGTH 

717B = 463 

CM LABELLED COMMON LENGTH 

152B = 106 

CM STORAGE USED 

63600B = 26496 

COMPILE TIME 

0.185 SECONDS 

Output and Interactive Response 

From Program Execution 

ENTER: INITIAL, RESTART, OR END 

? 'initial 1 

DATA BASE PROCESSING COMPLETED 







Figure 5-10. Program TRANPRG (Sheet 5 of 5) 
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File Description With Corresponding Read Statements 


A group of data items occuring NUN times 


TRANID 

INSTID 

INNJR 

NUN * 

IDENT 

COURS 

GRADE 

CODE 

DATE 

UNITS 

(CHAR 10) 

(CHAR 11) 

(CHAR 20) 

(INT 1) 

(CHAR 14) 

(CHAR 6) 

(REAL 3) 

(CHAR 1) 

(CHAR 8) 

(INT 1) 


> 


READ (5,*,ERR=45,END=55) 
TRANID,INSTID,INMJR,NUM 


READ (5,*,ERR=45,END=45) 
IDENT,COURS,GRADE,CODE,DATE,UNITS 


Data 


'A000000001' '100-22-5860' 'PSYCHOLOGY' 3 
'100-22-5860-05' 'PSY136' 4.0 'C' '9/30/80' 3 
'100-22-5860-06' 'BUS001' 3.0 'C' '9/30/80' 3 
•100-22-5860-07' 'PSY003' 3.5 'C' '9/30/80' 3 
'A000000002' '122-13-6704' 'BUSINESS' 2 
•122-13-6704-03' 'BUS017' 4.0 'C* '9/30/80' 3 
•122-13-6705-04' 'PSY003' 3.0 'C' '9/30/80' 3 
'A000000003' '687-14-2100' 'BI0L0G' 2 
'687-14-2100-05' 'PSY002' 4.0 'C' '9/30/80' 3 
'687-14-2100-06' 'BUS017' 3.5 'C' '9/30/80' 3 




Figure 5-11. Input File INTRAN and File Description for Program TRANPRG 
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Figure 5-6. Program INDAVGE (Sheet 2 of 4) 
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Figure 5 - 6 . Progre* INDAVGE (Sheet 4 of 4) 
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Figure 5-7. Program RELATE (Sheet 1 of 4) 
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PROGRAM-UNIT LENGTH 3010 = 193 

SCM LABELLED COMMON LENGTH 1520 = 106 

SCM STORAGE USED 60700B = 25024 

COMPILE TIME 0.057 SECONDS 
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Figure 5-8. Program CHARGES (Sheet 1 of 3) 
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Figure 5-8. Program CHARGES (Sheet 2 of 3) 
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Figure 5-8. Program CHARGES (Sheet 3 of 3) 
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Figure 5-9. Program ADMIT (Sheet 2 of 5) 
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Figure 5-9. Program ADMIT (Sheet 3 of 5) 
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USING THE CDCS BATCH TEST FACILITY 


6 


This user's guide assumes that CDCS is active and 
available for your job. This method of operation 
implies established schemas, appropriate sub-schema 
libraries, and successfully implemented applica¬ 
tions. Any change in the data base environment, 
such as the addition of a new file definition, 
forces the data administrator to terminate CDCS and 
to reinitiate CDCS with a new master directory file 
attached. By using the CDCS Batch Test Facility, 
you can have CDCS running as a normal batch job. 
Each time you run your job, you attach a new ver¬ 
sion of the master directory file. 

The CDCS Batch Test Facility is an absolute program 
called CDCSBTF. The program resides on the system 
library and is called into execution by the CDCSBTF 
control statement. The format and parameters of 
the CDCSBTF control statement are shown in figure 
6-1. The CDCSBTF control statement cannot exceed 
80 characters in length. A slash (/) indicates the 
end of the list of user program file names and the 
beginning of the parameter list. 

When CDCS is executing as the Batch Test Facility, 
the name of the output file produced by CDCS is 
CDCSOUT. 


DIRECTIVE FILE 

An optional directive file can be used to contain 
the parameters in addition to or instead of the 
parameters in the CDCSBTF control statement. Using 
a directive file allows specification of a param¬ 
eter list that is longer than that allowed in the 
control statement. With the exception of the MFL 
parameter, which cannot be specified in either the 
control statement or the directive file. The same 
parameter cannot, however, be specified in both the 
control statement and the directive file. Param¬ 
eters can be specified in any order in the directive 
file. Any of the parameters, except MFL or DIR, 
that are valid in the CDCSBTF control statement are 
also valid in the directive file. Parameters can 
be specified in the directive file in columns 1 
through 80. The first parameter specified in a 
line must begin in column 1. Parameters can either 
be placed in separate tines or combined in a line 
with commas acting as separators. Parameters can¬ 
not be split across lines. 


PARAMETERS 

All the parameters (figure 6-1) of the CDCSBTF 
control statement are optional and can be specified 
in any order. The CDCSBTF parameters provide 
information for the following functions: 

a Allocation of maximum pooled buffer space 


CDCSBTF(lfn-1 C,lfn-23 .. 

.C/pK,p] ...) 

Ifn 

Specifies the logical file name of a 
relocatable binary file containing a user 
program. Up to 16 files can be specified. 

/ 

The end of the user program list and the 
beginning of the parameter list 

P 

A parameter; the parameters are as follows: 


DIR=lfn 

Directive file for 
CDCSBTF control 
statement parameters 


BL=nn 

Maximum pooled buffer 
space 


CP=t1 

Central processor time 


X0=t2 

Input/output time 


MFL=fl 

Maximum field length 
for CDCSBTF 


CRM=fs1C/fs2D... 

Load CRM capsules 
where fs is a file 
structure as follows: 



AK 

DA 

IS 

MIP or MP 


MDPFN=pfn 
UN=user-name 
ID=user-name 
PW=pwrd1C/pwrd23 
FAM=family-name 
PN=pack-name 
DT=device-set 
SN=set-name 

1 Permanent file 
... \ information for 
t master directory 

1 file 


Figure 6-1. CDCSBTF Control Statement Format 


• Adjustment of accounting charges 

• Allocation of the maximum field length that 
CDCSBTF is allowed to use 

• Specification of information required to attach 
the master directory; these parameters must be 
given if online dumping of journal tog files is 
desired 

o Specification of a directive file that can 
contain any of the CDCSBTF control statement 
parameters except MFL and DIR 
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If the CP and 10 parameters are specified either in 
the CDCSBTF control statement or in the directive 
file, the accounting values return to the user's 
dayfile are different from the accounting values 
returned when the same application executes with 
COCS at the system control point. When CDCSBTF 
executes, the accounting values returned include 
the application's execution time as well as the 
central processor and input/output time charged by 
CDCS. 

The parameters available for the CDCSBTF control 
statement are the same as the parameters available 
for the CDCS control statement. See the CDCS Data 
Administrator's reference manual for more informa¬ 
tion about the parameters. 

REQUIREMENTS 

When you are running application programs with the 
CDCSBTF program, you must meet certain require¬ 
ments. These requirements are: 

• Attach the master directory file. It can be 
attached in two ways: either by information 
provided in the CDCSBTF control statement or 
directive file or by an ATTACH control state¬ 
ment that precedes execution of CDCSBTF. If 
the ATTACH control statement is used, the 
master directory file must be specified with 
the Local file name MSTRDIR. However, using 
this method of attaching the master directory 
prevents online dumping of journal Log files 
from being performed by CDCSBTF. 

• Have the application program in relocatable 
binary format as a local or a permanent file. 

• Assign unique names to non-CDCS files. Do not 
use any of the following names: 

INPUT 
OUTPUT 
MSTRDIR 
CDCSOUT 
Fnnnnnn \ 

Jnnnnnn I 
Pnnnnnn I 

Onnnnnn Mwhere n is any six digits) 

Rnnnnnn | 

Tnnnnnn 1 
Xnnnnnn / 

A name beginning with ZZZZZ 
A log file name 


* Be sure your application program executes a DML 
TERMINATE statement before a FORTRAN STOP or 
END statement. Failure to do this would dis¬ 
continue processing for all programs specified 
in the CDCSBTF control statement that have not 
completed execution. 


• Set the DB parameter in the FTN5 control state¬ 
ment equal to 0. Multiple copies of CDCSBTF 
can be run concurrently, and as many as 16 user 
programs can be run with a copy of CDCSBTF. If 
more than two concurrent calls to the RECOVR 
routine are made, CDCS aborts processing. 


OBTAINING LOAD MAPS 

You can obtain load maps by setting sense switches 
1 through 4 prior to execution of the CDCSBTF 
control statement. Each sense switch setting cor¬ 
responds to different information on the load map. 
The settings and the associated types of informa¬ 
tion are shown in table 6-1. 


TABLE 6-1. LOAD MAP SWITCH SETTINGS 


Setting 

Load Map Information 

SWITCH(1) 

Statistics CS) 

$WITCH<2> 

Block maps (B) 

SWITCH(3) 

Entry point maps (E0) 

SWITCH(4) 

Entry point cross-reference maps (X). 


EXECUTING THE CDCS BATCH 
TEST FACILITY 

You need to include a number of control statements 
when executing the CDCS Batch Test Facility for 
your FORTRAN application program. Figure 6-2 
provides a sample list of statements. Parameters 
correspond to the application that appears in 
appendix C. 


6-2 
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NOS Operating System 

NOS/BE Operating System 


Jobname,CMfl. 

Jobname,CMfl. 

Names the job and specifies maximum 
field length. 

USER statement 


Identifies the user. 

CHARGE statement 


Specifies the account to which the 
job's use of system resources is 
logged. 

ATTACH,SSLIB/UN=xxx. 

ATTACH,SSLIB,ID=xxx. 

Attaches the sub-schema. 

DML,SB=SSLIB,LV=F5 

DML,SB=SSLIB,LV=F5 

Preprocesses the DHL statements in 
the FORTRAN program and writes to 
DMLOUT. 

FTN5,I=DML0UT,DB=0. 

FTN5,I=DML0UT,DB=0. 

Compiles the FORTRAN program on 

DMLOUT and places it on the LGO file. 

SWITCH,2. 

SWITCH,2. 

Requests block map on 
program-initiated load. 

SWITCH,3. 

SWITCH,3. 

Requests entry point map on 
program-initiated load. 

SWITCH,4. 

SWITCH,4. 

Requests entry point cross reference 
map on program-initiated load. 

LIBRARY,DMSLIB. 

LIBRARY,DMSLIB. 

Specifies that library DMSLIB is to 
be used to satisfy externals. 

CDCSBTF,LGO/MDPFN=MSTRDIR,UN=xxx. 

CDCSBTF,LGO/MDPFN=MSTRDIR,ID=xxx. 

Executes CDCSBTF and passes the 
master directory permanent file 
information as parameters.. 

REWIND,COCSOUT. 

REWIND,CDCSOUT. 

Rewinds the CDCSBTF output file. 

COPY,CDCSOUT,OUTPUT. 

COPY,CDCSOUT,OUTPUT. 

Prints the CDCSBTF output file. 

CRMEP. 

CRMEP. 

Prints the CRM error file. 

EXIT. 

EXIT. 

Establishes processing if error 
occurs. 

DMD. 

DMP. 

Dumps the exchange package. 

DMD,377000. 

DMP,377000. 

Dumps the contents of the field 
length. 

CRMEP. 

CRMEP. 

Prints the CRM error file. 

REWIND,CDCSOUT. 

REWIND,CDCSOUT. 

Rewinds the CDCSBTF output file. 

COPY,CDCSOUT,OUTPUT. 

COPY,CDCSOUT,OUTPUT. 

Prints the CDCSBTF output file. 



Figure 6-2. Sample FORTRAN 5 Execution of COCS Batch Test Facility 
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TABLE A-3. ASCII CHARACTER SET COLLATING SEQUENCE 


Collating 

Sequence 

Decimal/Octal 

ASCII 

Graphic 

Subset 


ASCII 

Code 

Collating 

Sequence 

Decimal/Octal 

ASCII 

Graphic 

Subset 

Display 

Code 

ASCII 

Code 

00 

00 

blank 

55 

20 

32 

40 

@ 

74 

40 

01 

01 

I 

66 

21 

33 

41 

A 

01 

41 

mm 

■a 

u 

64 

22 

34 

42 

B 

•IW 

42 

19 

■a 

# 

60 

23 

35 

43 

C 

ES 

43 

04 

04 

$ 

53 

24 

36 

44 

D 

04 

44 

05 

05 

% 

63t 

25 

37 

45 

E 

05 

45 

06 

06 

& 

67 

26 

38 

46 

F 

06 

46 

07 

07 

t 

70 

27 

39 

47 

G 

07 

47 

08 

10 

( 

51 

28 

40 

50 

H 

10 

48 

09 

11 

) 

52 

29 

41 

51 

1 

11 

49 

10 

12 

* 

47 

2A 

42 

52 

J 

12 

4A 

11 

13 

+ 

45 

2B 

43 

53 

K 

13 

4B 

12 

14 


56 

2C 

44 

54 

L 

14 

4C 

13 

15 


46 

2D 

45 

55 

M 

15 

4D 

14 

16 


57 

2E 

46 

56 

N 

16 

4E 

15 

17 

/ 

50 

2F 

47 

57 

O 

17 

4F 

16 

20 

0 

33 

30 

48 

60 

P 

20 

50 

17 

21 

1 

34 

31 

49 

61 

Q 

21 

51 

18 

22 

2 

35 

32 

50 

62 

R 

22 

52 

19 

23 

3 

36 

33 

51 

63 

S 

23 

53 

20 

24 

4 

37 

34 

52 

64 

T 

24 

54 

21 

25 

5 

40 

35 

53 

65 

U 

25 

55 

22 

26 

6 

41 

36 

54 

66 

V 

26 

56 

23 

27 

7 

42 

37 

55 

67 

w 

27 

57 

24 

30 

8 

43 

38 

56 

70 

X 

30 

58 

25 

31 

9 

44 

39 

57 

71 

Y 

31 

59 

26 

32 

: 

oot 

3A 

58 

72 

z 

32 

5A 

27 

33 

t 

77 

3B 

59 

73 

[ 

61 

5B 

28 

34 

< 

72 

3C 

60 

74 

\ 

75 

5C 

29 

35 

= 

54 

3D 

61 

75 

] 

62 

5D 

30 

36 

> 

73 

3E 

62 

76 

/s 

76 

5E 

31 

37 

? 

71 

3F 

63 

77 

— 

65 

5F 

fin installations using a 63-graphic set, the % graphic does not exist. The : graphic 
is display code 63. 














NOS Operating System 

NOS/BE Operating System 


Jobname,CMfl. 

J obname,CMfl. 

Names the job and specifies maximum 
field length. 

USER statement 


Identifies the user. 

CHARGE statement 


Specifies the account to which the 
job's use of system resources is 
logged. 

ATTACH,SSLIB/UN=xxx. 

ATTACH,$SLIB,ID=xxx. 

Attaches the sub-schema. 

DML,SB=SSLIB,LV=F5 

DML,SB=SSLIB,LV=F5 

Preprocesses the DML statements in 
the FORTRAN program and writes to 
DMLOUT. 

FTN5,I=DML0UT,DB=0. 

FTN5,I=DML0UT,DB=0. 

Compiles the FORTRAN program on 

DMLOUT and places it on the LGO file. 

SWITCH,2. 

SWITCH, 2. 

Requests block map on 
program-initiated load. 

SWITCH,3. 

SWITCH,3. 

Requests entry point map on 
program-initiated load. 

SWITCH,4. 

SWITCH,4. 

Requests entry point cross reference 
map on program-initiated load. 

LIBRARY,DMSLIB. 

LIBRARY,DMSLIB. 

Specifies that library DMSLIB is to 
be used to satisfy externals. 

CDCSBTF,LGO/MDPFN=MSTRDIR,UN=xxx. 

CDCSBTF,LGO/MDPFN=MSTRDIR,ID=xxx. 

Executes CDCSBTF and passes the 
master directory permanent file 
information as parameters.. 

REWIND,CDCSOUT. 

REWIND,CDCSOUT. 

Rewinds the CDCSBTF output file. 

COPY,C DCSOUT,OUTPUT. 

COPY,CDCSOUT,OUTPUT. 

Prints the CDCSBTF output file. 

CRMEP. 

CRMEP. 

Prints the CRM error file. 

EXIT. 

EXIT. 

Establishes processing if error 
occurs. 

DND. 

DMP. 

Dumps the exchange package. 

DMD,377000. 

DMP,377000. 

Dumps the contents of the field 
length. 

CRMEP. 

CRMEP. 

Prints the CRM error file. 

REWIND,CDCSOUT. 

REWIND,CDCSOUT. 

Rewinds the CDCSBTF output file. 

COPY,CDCSOUT,OUTPUT. 

COPY,CDCSOUT,OUTPUT. 

Prints the CDCSBTF output file. 


Figure 6-2. Sample FORTRAN 5 Execution of CDCS Batch Test Facility 
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STANDARD CHARACTER SETS 


A 


Control Data operating systems offer the following 
variations of a basic character set: 

• CDC 64-character set 

• CDC 63-character set 

• ASCII 64-character set 

q ASCII 63-character set 


The set in use at a particular installation was 
specified when the operating system was installed 
or (for NOS only) dead started. 

Depending on another installation option, the 
system assumes an input deck has been punched 
either in 026 or in 029 mode (regardless of the 
character set in use). Under NOS/BE, the alternate 
mode can be specified by a 26 or 29 punched in 
columns 79 and 80 of the job statement or any 7/8/9 
card. The specified mode remains in effect through 


the end of the job unless it is reset by 
specification of the alternate mode on a subsequent 
7/8/9 card. 

Under NOS, the alternate mode can be specified also 
by a 26 or 29 punched in columns 79 and 80 of any 
6/7/9 card, as described previously for a 7/8/9 
card. In addition, 026 mode can be specified by a 
card with 5/7/9 multipunched in column 1, and 029 
mode can be specified by a card with 5/7/9 
multipunched in column 1 and a 9 punched in 
column 2. 

Graphic character representation appearing at a 
terminal or printer depends on the installation 
character set and the terminal type. Characters 
shown in the CDC Graphic column of the standard 
character set table (table A-1) are applicable to 
BCD terminals; ASCII graphic characters are 
N applicable to ASCII-CRT and ASCII-TTY terminals. 

Standard collating sequences for the two printer 
character sets are shown in tables A-2 and A-3. 


A-1 
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TABLE A-1. STANDARD CHARACTER SETS 


Display 

Code 

(octal) 


CDC 

1 ASCII ] 

Graphic 

Hollerith 

Punch 

(026) 

External 

BCD 

Code 

Graphic 

Subset 

Punch 

(029) 

Code 

(octal) 

00 f 

: (colon) 

8-2 

00 

: (colon) 

8-2 

072 

01 

A 

12-1 

61 

A 

12-1 

101 

02 

B 

12-2 

62 

B 

12-2 

102 

03 

C 

12-3 

63 

C 

12-3 

103 

04 

D 

12-4 

64 

D 

12-4 

104 

05 

E 

12-5 

65 

E 

12-5 

105 

06 

F 

12-6 

66 

F 

12-6 

106 

07 

G 

12-7 

67 

G 

12-7 

107 

10 

H 

12-8 

70 

H 

12-8 

110 

11 

1 

12-9 

71 

| 

12-9 

111 

12 

J 

11-1 

41 

J 

11-1 

112 

13 

K 

11*2 

42 

K 

11-2 

113 

14 

L 

11-3 

43 

L 

11-3 

114 

15 

M 

11-4 

44 

M 

11-4 

115 

16 

N 

11-5 

45 

N 

11-5 

116 

17 

O 

11*6 

46 

0 

11-6 

117 

20 

P 

11-7 

47 

P 

11-7 

120 

21 

Q 

11-8 

50 

Q 

11-8 

121 

22 

R 

11-9 

51 

R 

11-9 

122 

23 

S 

0-2 

22 

S 

0-2 

123 

24 

T 

0-3 

23 

T 

0-3 

124 

25 

U 

0-4 

24 

U 

0-4 

125 

26 

V 

0*5 

25 

V 

0-5 

126 

27 

w 

0-6 

26 

w 

0-6 

127 

30 

X 

0-7 

27 

X 

0-7 

130 

31 

Y 

0-8 

30 

Y 

0-8 

131 

32 

z 

0-9 

31 

z 

0-9 

132 

33 

0 

0 

12 

0 

0 

060 

34 

1 

1 

01 

1 

1 

061 

35 

2 

2 

02 

2 

2 

062 

36 

3 

3 

03 

3 

3 

063 

37 

4 

4 

04 

4 

4 

064 

40 

5 

5 

05 

5 

5 

065 

41 

6 

6 

06 

6 

6 

066 

42 

7 

7 

07 

7 

7 

067 

43 

8 

8 

10 

8 

8 

070 

44 

9 

9 

11 

9 

9 

071 

45 

+ 

12 

60 

+ 

12-8-6 

053 

46 

j|r 

11 

40 

• 

11 

055 

47 


11-8-4 

54 

♦ 

11-8-4 

052 

50 

/ 

0-1 

21 

1 

0-1 

057 

51 

( 

0-8-4 

34 

( 

12-8-5 

050 

52 

) 

12-8*4 

74 

) 

11-8-5 

051 

53 

$ 

11-8-3 

53 

$ 

11-8-3 

044 

54 

= 

8-3 

13 

= 

8-6 

075 

55 

blank 

no punch 

20 

blank 

no punch 

040 

56 

, (comma) 

0-8-3 

33 

, (comma) 

0-8-3 

054 

57 

. (period) 

12-8-3 

73 

. (period) 

12-8-3 

056 

60 

= 

0-8-6 

36 

# 

8-3 

043 

61 

i 

8-7 

17 

C 

12-8-2 

133 

62 

i t+ 

0-8-2 

32 

3 

11-8-2 

135 

63 

%tt 

8-6 

16 


0-8-4 

045 

64 

* 

8-4 

14 

" (quote) 

8-7 

042 

65 

r~ 

0-8-5 

35 

(underline) 

0-8-5 

137 

66 

V 

11-0 

52 

I 

12-8-7 

041 

67 

A 

0-8-7 

37 

& 

12 

046 

70 

t 

11-8-5 

55 

1 (apostrophe) 

8-5 1 

047 

71 

» 

11-8-6 

56 

? 

0-8-7 

077 

72 

< 

12-0 

72 

< 

12-8-4 

074 

73 

> 

11-8-7 

57 

> 

0-8-6 

076 

74 

< 

8-5 

15 

<§> 

84 

100 

75 

> 

12-8-5 

75 

\ 

0-8-2 

134 

76 

—» 

12-8-6 

76 

- (circumflex) 

11-8-7 

136 

77 

; (semicolon) 

12-8-7 

77 

; (semicolon) 

11-8-6 

073 


^Twelve zero bits at the end of a 60-bit word in a zero byte record are an end of record mark rather than 
two colons. 

In installations using a 63-graphic set, display code 00 has no associated graphic or card code; display 
code 63 is the colon (8-2 punch). The % graphic and related card codes do not exist and translations 
yield a blank (55g). 
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TABLE A-2. CDC CHARACTER SET COLLATING SEQUENCE 


Collating 

Sequence 

Decimal/Octal 

CDC 

Graphic 

Display 

Code 

External 

BCD 

Collating 

Sequence 

Decimal/Octal 

CDC 

Graphic 

Display 

Code 

External 

BCD 

00 

00 

blank 

55 

20 

32 

40 

H 

10 

70 

01 

01 

< 

74 

15 

33 

41 

1 

11 

71 

02 

02 

% 

63 t 

16 t 

34 

42 

V 

66 

52 

03 

03 

[ 

61 

17 

35 

43 

J 

12 

41 

04 

04 

—* 

65 

35 

36 

44 

K 

13 

42 

05 

05 

= 

60 

36 

37 

45 

L 

14 

43 

06 

06 

A 

67 

37 

38 

46 

M 

15 

44 

07 

07 

t 

70 

55 

39 

47 

N 

16 

45 

08 

10 

1 

71 

56 

40 

50 

0 

17 

46 

09 

11 

> 

73 

57 

41 

51 

P 

20 

47 

10 

12 

> 

75 

75 

42 

52 

Q 

21 

50 

11 

13 


76 

76 

43 

53 

R 

22 

51 

12 

14 

. 

57 

73 

44 

54 

) 

62 

32 

13 

15 

) 

52 

74 

45 

55 

S 

23 

22 

14 

16 

t 

77 

77 

46 

56 

T 

24 

23 

15 

17 

+ 

45 

60 

47 

57 

U 

25 

24 

16 

20 

$ 

53 

53 

48 

60 

V 

26 

25 

17 

21 

« 

47 

54 

49 

61 

w 

27 

26 

18 

22 

- 

46 

40 

50 

62 

X 

30 

27 

19 

23 

/ 

50 

21 

51 

63 

Y 

31 

30 

20 

24 

9 

56 

33 

52 

64 

z 

32 

31 

21 

25 

( 

51 

34 

53 

65 


00 t 

nonet 

22 

26 

= 

54 

13 

54 

66 

0 

33 

12 

23 

27 

* 

64 

14 

55 

67 

1 

34 

01 

24 

30 

< 

72 

72 

56 

70 

2 

35 

02 

25 

31 

A 

01 

61 

57 

71 

3 

36 

03 

26 

32 

B 

02 

62 

58 

72 

4 

37 

04 

27 

33 

C 

03 

63 

59 

73 

5 

40 

05 

28 

34 

D 

04 

64 

60 

74 

6 

41 

06 

29 

35 

E 

05 

65 

61 

75 

7 

42 

07 

30 

36 

F 

06 

66 

62 

76 

8 

43 

10 

31 

37 

G 

07 

67 

63 

77 

9 

44 

11 

t|n installations using the 63-graphic set, the % graphic does not exist. The : graphic is display code 63, 

External BCD code 16. 
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TABLE A-3. ASCII CHARACTER SET C0LLATIN6 SEQUENCE 


Collating 

Sequence 

Decimal/Octal 

ASCII 

Graphic 

Subset 

1 

1 

ASCII 

Code 

Collating 

Sequence 

Decimal/Octal 

ASCII 

Graphic 

Subset 

Display 

Code 

ASCII 

Code 

00 

00 

blank 

55 

20 

32 

40 

@ 

74 

40 

01 

01 

! 

66 

21 

33 

41 

A 

01 

41 

mm 

mm 

n 

64 

22 

34 

42 

B 

mm 

42 

wBm 

mm 

# 

60 

23 

35 

43 

C 

WEM 

43 

04 

04 

$ 

53 

24 

36 

44 

D 

04 

44 

05 

05 

% 

63t 

25 

37 

45 

E 

05 

45 

06 

06 

& 

67 

26 

38 

46 

F 

06 

46 

07 

07 

t 

70 

27 

39 

47 

G 

07 

47 

08 

10 

( 

51 

28 

40 

50 

H 

10 

48 

09 

11 

) 

52 

29 

41 

51 

1 

11 

49 

10 

12 

« 

47 

2A 

42 

52 

J 

12 

4A 

11 

13 

+ 

45 

2B 

43 

53 

K 

13 

4B 

12 

14 


56 

2C 

44 

54 

L 

14 

4C 

13 

15 


46 

2D 

45 

55 

M 

15 

40 

14 

16 


57 

2E 

46 

56 

N 

16 

4E 

15 

17 

/ 

50 

2F 

47 

57 

O 

17 

4F 

16 

20 

0 

33 

30 

48 

60 

P 

20 

50 

17 

21 

1 

34 

31 

49 

61 

Q 

21 

51 

18 

22 

2 

35 

32 

50 

62 

R 

22 

52 

19 

23 

3 

36 

33 

51 

63 

S 

23 

53 

20 

24 

4 

37 

34 

52 

64 

T 

24 

54 

21 

25 

5 

40 

35 

53 

65 

U 

25 

55 

22 

26 

6 

41 

36 

54 

66 

V 

26 

56 

23 

27 

7 

42 

37 

55 

67 

w 

27 

57 

24 

30 

8 

43 

38 

56 

70 

X 

30 

58 

25 

31 

9 

44 

39 

57 

71 

1 

Y 

31 

59 

26 

32 

; 

oot 

3A 

58 

72 

z 

32 

5A 

27 

33 

• 

77 

3B 

59 

73 

[ 

61 

5B 

28 

34 

< 

72 

3C 

60 

74 

\ 

75 

5C 

29 

35 

z= 

54 

3D 

61 

75 

) 

62 

5D 

30 

36 

> 

73 

3E 

62 

76 


76 

5E 

31 

37 

? 

71 

3F 

63 

77 

— 

65 

5F 


tin installations using a 63-graphic set, the % graphic does not exist. The : graphic 
is display code 63. 
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GLOSSARY 


B 


Access Control - 

Protection of data from unauthorized access or 
modification. 

Actual Key - 

A file organization in which records are stored 
according to their system-assigned key values. 

Advanced Access Methods (AAM) - 

A file manager that processes indexed sequen¬ 
tial, direct access, and actual key file 
organizations and supports the Multiple-Index 
Processor. See CYBER Record Manager. 

Alias - 

A data name used in the sub-schema in place of 
a schema data name. 

Area - 

A uniquely named schema data base subdivision 
that contains data records; identified in the 
sub-schema as a realm; a file in the operating 
system. 

Automatic Recovery - 

CDCS initiated recovery operations that make a 
data base usable and consistent after some type 
of software or hardware failure (but not media 
failure). 


Basic Access Methods (BAM) - 

A file manager that processes sequential and 
word addressable file organizations. See CYBER 
Record Manager. 

CDCS - 

See CYBER Database Control System. 

CDCS Batch Test Facility - 

A facility that allows an application to simu¬ 
late a data base environment without impacting 
any other CDCS users on the system. 

Chi Id Record Occurrence - 

For relation processing, a record occurrence 
that has another record occurrence (the parent 
record occurrence) at the next numerically 
| lower rank in the relation. 

Common Item - 

A data item that appears in two or more files 
joined in a relation; in each instance, the 
data item contains the same value. 

Concurrency - 

Simultaneous access to the same data in a data 
base by two or more application programs during 
a given span of time. 

Constraint - 

A control imposed on records in related files 
or on items in a single file for the purpose of 
protecting the integrity of data in a data base 
during update operations. A constraint is 
defined in the schema and is based on the com¬ 
mon item in the records. 


Control Break - 

A condition that occurs during a relation read 
to signify a new record occurrence was read for 
the parent file. 

CRM - 

See CYBER Record Manager. 

CYBER Database Control System (CDCS) - 

The controlling module that provides the inter¬ 
face between the application program and the 
data base. 

CYBER Record Manager (CRM) - 

A generic term relating to the common products 
BAM and AAM, which run under the NOS and NOS/BE 
operating systems and allow a variety of record 
types, block types, and file organizations to 
be created and accessed. The execution time 
input/output of the DMS-170 products is imple¬ 
mented through CRM. All CRM file processing 
requests ultimately pass through the operating 
system input/output routines. 

Data Administrator - 

A person who defines the format and organiza¬ 
tion of the data base. 

Data Base - 

A systematically organized, central pool of 
information; organization is described by a 
schema. 

Data Base Procedure - 

A special-purpose routine that performs a pre¬ 
defined operation; specified in the schema and 
initiated by CDCS. 

Data Base Status Block - 

An array defined within an application program 
to which CDCS returns information concerning 
the status of operations on data base files and 
relations. The status block is updated after 
each CDCS operation. 

Data Base Transaction - 

A series of update operations identified by a 
user-assigned transaction identifier. A data 
base transaction is bracketed by a begin trans¬ 
action operation and either a commit or drop 

operation. Data base transactions also provide 
a program restart capability that can be used 
for restarting an application program after a 
system failure. 

Data Base Version - 

A set of data files that is described by a 

schema. Data base versions are defined in the 
master directory. When data base versions are 
used, a schema (the description of the data 

base) can be used with more than one set of 
files (each set of files being a data base 

version). 

Data Description Language (DDL) - 

The language used to structure the schema and 
the sub-schema. 
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Data Item - 

A unit of data within a record; can be a vari¬ 
able or an array in the FORTRAN sub-schema. 

Data Manipulation Language (DHL) - 

The extensions to FORTRAN that provide access 
to a DMS-170 data base. 

DDL - 

See Data Description Language. 

Deadlock - 

A situation that arises in concurrent data base 
access when two or more application programs, 
each with locked resources, are contending for 
a resource that is locked by one of the other 
application programs, and none of the programs 
can proceed without that resource. 

Dependent Record Occurrence - 

A record occurrence that is the dependent 
member of a condition defined by a constraint. 

Direct Access - 

In the context of CRM, one of the five file 
organizations. The organization is character¬ 
ized by the system hashing of the unique key 
within each file record to distribute records 
randomly in blocks called home blocks of the 
fi le. 

In the context of NOS permanent files, a file 
that is accessed and modified directly, as 
contrasted with an indirect access permanent 
fi le. 

DML - 

See Data Manipulation Language. 

Dominant Record Occurrence - 

A record occurrence that is the dominant member 
of a condition defined by a constraint. 

Exclusive Locking - 

Locking mechanism that allows one program 
access to a realm or record and prohibits all 
access by other users. Contrast with Protected 
Locking. 

File - 

A collection of records treated as a unit; an 
area in the schema; a realm in the sub-schema. 

Hierarchical Tree Structure - 

A representation that commonly illustrates 
record occurrences for files joined in a 
directed relation. The root of the tree is a 
record occurrence in the root file, and each 
successive level represents the record occur¬ 
rences in each joined file. 

Home Block - 

Mass storage allocated for a file with direct 
access organization at the time the file is 
created. 

Indexed Sequential - 

A file organization in which records are stored 
in ascending order by.key. 

Keyword - 

A word that is required in a source program 
statement. 


Log Files - 

Files that hold historical records of opera¬ 
tions performed by users on data base areas. 

Mapping - 

The process by which CDCS produces a record or 
item image conforming to the schema or sub¬ 
schema description. 

Master Directory - 

A file created by the data administrator and 
used by CDCS in processing. This information 
consists of schema and sub-schema tables, media 
parameters, and data base procedure library and 
logging specifications. 

Multiple-Index Processor - 

A processor that allows AAM files to be accessed 
by alternate keys. 


Null Record Occurrence - 

A record occurrence composed of the display 
code right bracket symbol in each character 
position. The null record occurrence is used 
in a relation occurrence to denote that no 
record occurrence qualifies or that a record 
occurrence does not exist at a given level in 
the relation. 


Operation - 

A particular function performed on units of 
data; for instance, opening or closing an area, 
or storing or deleting a record. 

Parent Record Occurrence - 

For relation processing, a record occurrence 
that has another record occurrence at the next 
numerically higher rank in the relation. 

Permanent File - 

A file that resides on a mass storage permanent 
file device and can be retained for longer than 
a single job. The file is protected against 
accidental destruction and can be protected 
against unauthorized access. 

Privacy Key - 

A character constant, variable name, or unsub- 
scripted name that is included in a FORTRAN DML 
PRIVACY statement to gain access to a particu¬ 
lar realm. 

Protected Locking - 

Locking mechanism that allows one program 
access to a realm or record for update opera¬ 
tions and prohibits update operations (allows 
read operations) by other users. Contrast with 
Exclusive Locking. 


Rank - 

The rank of a file in a relation corresponds to 
the position of the file in the schema defini¬ 
tion of the relation. The ranks of the files 
joined in a relation are numbered consecutively, 
with the root file having a rank of 1. 

Realm - 

A uniquely named sub-schema data base subdivi¬ 
sion that contains data records; identified in 
the schema as an area; a file. 
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Realm Ordinal - 

A unique identifier assigned to each realm in a 
sub-schema when the sub-schema is compiled. 
Sub-schema realm ordinals are used in conjunc¬ 
tion with the data base status block. 

Record - 

A named collection of one or more data items 
that are treated as a unit. 

Record Occurrence - 

An actual data base record that conforms to a 
record description in the schema. 

Record Type - 

The description of the attributes of a record; 
record layout. 

Recovery - 

A process that makes a data base useful after 
some type of software or hardware failure has 
occurred. 

Relation - 

A group of files that are related by common 
data items; therefore the files can be opened, 
closed, or read by a single request. Relations 
are defined in the schema. 

Relation Occurrence - 

The logical concatenation of a record occur¬ 
rence from each record type specified in the 
relation. 

Restart Identifier - 

A unique identifier for a run-unit that is 
maintained by CDCS for program restart opera¬ 
tions in data base transactions. 

Restart Identifier File - 

A random permanent file used internally by CDCS 
to support program restart operations for 
programs that request a restart identifier. 


Restriction - 

Criteria that must be satisfied by a record 
occurrence in a relation before it can be made 
available to the application program. Restric¬ 
tions are defined in the sub-schema. 

Root Realm - 

The first realm listed in a relation; the root 
realm has the rank of 1 in a relation; record 
occurrences of the root realm are pictured as 
the root of a tree in a hierarchical tree 
structure. 

Schema - 

A detailed description of the internal struc¬ 
ture of the complete data base. 

Status Block - 

See Data Base Status Block. 

Sub-Schema - 

A detailed description of the portion of the 
data base to be made available to one or more 
application programs. 

Sub-Schema Item Ordinal - 

An identifier, unique within a record, assigned 
to each item in a sub-schema when the sub-schema 
is compiled. Sub-schema item ordinals are used 
in conjunction with the data base status block. 

Sub-Schema Library - 

A permanent file containing one or more sub¬ 
schemas. 

Transaction - 

See Data Base Transaction. 

Transaction Identifier - 

A user-assigned identifier for a data base 
transaction. The identifier is used for program 
restart operations in data base transactions. 
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THE SAMPLE APPLICATION 


C 


This appendix contains the source programs and 
control statements used to generate the data base 
environment for the university application pre¬ 
sented in this user's guide- Although all programs 
reflect operation under the NOS operating system, 
conversion to the NOS/BE operating system could be 
accomplished by making the following changes: 


• Substitute the NOS/BE REQUEST and CATALOG 
control statements for the NOS DEFINE control 
statement. 


• Substitute the NOS/BE file identification 
parameter ID for the NOS file identification 
parameter UN. This substitution applies to the 
source input for the master directory. 


Setting up a DMS-170 data management environment is 
a data administrator responsibility; the process is 
shown here, however, to allow the reader to dup¬ 
licate the application and use it to gain an 
understanding of DMS-170 FORTRAN application pro¬ 
gramming. The source input for the jobs shown in 
this appendix illustrates the university applica¬ 
tion being created by a series of batch jobs. The 
source input for each job is shown exactly as 
required for processing on NOS with two exceptions: 

• End-of-record is indicated by the statement 
end-of-record and a blank line that is inserted 
to improve readability of the text. 


o End of input for the job is indicated by the 
statement end-of-information. 


The steps the data administrator takes to establish 
the application are listed in appropriate order as 
follows: 

1. Design, write, compile, and store the schema 
definition as a permanent file. A schema named 
UNIVERSITY is stored as a permanent file named 
UNIVERS. See figure C-1. 


2. Design, write, compile, and store sub-schema 
definitions as a permanent file library. A 
FORTRAN sub-schema library is stored as a 
permanent file named SSLIB. Input consists of 
four separate sub-schemas (AVERAGE, RELATION, 
ADMISSIONS, BURSAR); the sub-schemas follow 
each other with no intervening end-of-records. 
See figure C-2 for both source input and the 
listing that results from compilation. The 
FORTRAN sub-schema CREATES is used to create 
the data base and is stored in a permanent file 
library named CREATES. See figure C-3. 

3. Generate a master directory through the DBMSTRD 
utility. A master directory is stored as a 
permanent file named MSTRDIR. See figure C-4. 

4. Initialize log or recovery files specified for 
the schema in the master directory. The master 
directory specifies a transaction recovery file 
and a restart identifier file for schema 
UNIVERSITY. The DBREC utility is used to 
initialize these files. For processing on 
NOS/BE, the series of control statements that 
must be executed for each log and recovery file 
before the DBREC control statement is executed 
is as follows: REQUEST, REWIND, CATALOG, AND 
RETURN. See figure C-5. 

5. Write a program to store the data base. A 
FORTRAN program creates five data base files 
(PROFESSOR, COURSE, STUDENT, CURRICULUM, 
ACCOUNTING) using the FORTRAN sub-schema 
CREATES, and defines the appropriate index 
files assigned in the master directory. See 
figure C-6. CDCSBTF is used to run this pro¬ 
gram; therefore, CDCS does not have to be 
active. For processing on NOS/BE, the series 
of control statements that must be executed for 
each area and index file before the FTN5 con¬ 
trol statement is executed is as follows: 
REQUEST, REWIND, CATALOG, and RETURN. 

6. Establish CDCS as an active system. This must 
be done by the data administrator; the process 
is not shown in this guide. If CDCS is not 
established as an active system CDCSBTF can be 
used. 
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Job statement 


DATA CONTROL. 

USER statement 



CHARGE statement 


AREA NAME IS PROFESSOR 

FILE(PROFESS,F0=IS,XN=PNDX) 

KEY IS PROF-ID OF PROF-REC 

FILE(COURSE,FO=IS,XN=CRSNDX) 

DUPLICATES ARE NOT ALLOWED 

FILE(STUDENT,FO=IS,XN=SNDX> 

KEY IS ALTERNATE ACADEMIC-FIELD 

FILE(CURRICU,FO=IS,XN=CRNDX) 

DUPLICATES ARE ALLOWED. 

F ILE ( ACCOUNT, F0=IS) 



DEFINE(UNIVERS=UNIVERS/CT=PU,M=R> 

AREA NAME IS COURSE 

DDL3(DS,SC=UNIVERS) 


KEY IS COURSE-ID OF COURSE-REC 

End-of-record 


DUPLICATES ARE NOT ALLOWED 



KEY IS ALTERNATE PROF-ID OF COURSE-REC 

SCHEMA NAME IS UNIVERSITY. 

DUPLICATES ARE ALLOWED. 

AREA NAME IS PROFESSOR. 

AREA NAME IS STUDENT 

RECORD IS PROF-REC WITHIN PROFESSOR. 

KEY IS STUDENT-ID OF STUDENT-REC 



DUPLICATES ARE NOT ALLOWED 

PROF-ID 

TYPE CHARACTER 8. 

KEY IS ALTERNATE MAJOR 

PROF-NAME 

PICTURE "X<30>". 

DUPLICATES ARE ALLOWED. 

ACADEMIC-FIELD 

TYPE CHARACTER 20. 




AREA NAME IS CURRICULUM 

AREA NAME IS COURSE. 


KEY IS IDENT 

RECORD IS COURSE-REC 

WITHIN COURSE. 

KEY IS ALTERNATE STUDENT-ID OF CURR-REC 



DUPLICATES ARE ALLOWED 

COURSE-ID 

TYPE CHARACTER 6. 

KEY IS ALTERNATE COURSE-ID OF CURR-REC 

COURSE-NAME 

PICTURE "X(20) M . 

DUPLICATES ARE ALLOWED 

SCHOOL 

PICTURE "X(20>”. 

KEY IS ALTERNATE GRADE 

PROF-ID 

TYPE CHARACTER 8. 

DUPLICATES ARE ALLOWED. 

PREREQUISITE 

TYPE CHARACTER 6. 


UNITS 

TYPE DECIMAL. 

AREA NAME IS ACCOUNTING 



KEY IS STUDENT-ID OF ACCT-REC 

AREA NAME IS STUDENT 

a 

DUPLICATES ARE NOT ALLOWED. 

RECORD IS STUDENT-REC WITHIN STUDENT. 




CONSTRAINT NAME IS CONI 

STUDENT-ID 

TYPE CHARACTER 11. 

STUDENT-ID OF CURR-REC DEPENDS ON 

STUDENT-NAME 

PICTURE "X<30>". 

STUDENT-ID OF STUDENT-REC. 

STREET-ADDRESS 

PICTURE "X(20>". 


CITY 

PICTURE H X(10)”. 

CONSTRAINT NAME IS C0N2 

STATE 

PICTURE "A(2)". 

STUDENT-ID OF ACCT-REC DEPENDS ON 

ZIP-CODE 

PICTURE "X(5)". 

STUDENT-ID OF STUDENT-REC. 

PHONE 

PICTURE "X<12>". 


MAJOR 

TYPE CHARACTER 20. 

CONSTRAINT NAME IS C0N3 



COURSE-ID OF CURR-REC DEPENDS ON 

AREA NAME IS CURRICULUM E 

COURSE-ID OF COURSE-REC. 

ACCESS-CONTROL LOCK 

IS "XX99". 


RECORD IS CURR-REC WITHIN CURRICULUM. 

RELATION NAME IS REL1 



JOIN WHERE STUDENT-ID OF STUDENT-REC 

ID ENT 

TYPE CHARACTER 14. 

EQ STUDENT-ID OF CURR-REC. 

STUDENT-ID 

TYPE CHARACTER 11. 


COURSE-ID 

TYPE CHARACTER 6. 

RELATION NAME IS REL2 

GRADE 

TYPE FLOAT 

JOIN WHERE STUDENT-ID OF STUDENT-REC 


CHECK VALUE 0.0 THRU 4.0. 

EQ STUDENT-ID OF ACCT-REC. 

COMPLETE-CODE 

TYPE CHARACTER 1. 


COMPLETE-DATE 

TYPE CHARACTER 8. 

RELATION NAME IS REL3 

UNITS 

TYPE DECIMAL. 

JOIN WHERE PROF-ID OF PROF-REC 



EQ PROF-ID OF COURSE-REC 

AREA NAME IS ACCOUNTING. 

COURSE-ID OF COURSE-REC 

RECORD IS ACCT-REC WITHIN ACCOUNTING. 

EQ COURSE-ID OF CURR-REC. 



End-of-record 

01 STUDENT-ID 

TYPE CHARACTER 11. 


01 TUITION 

TYPE FLOAT OCCURS 16 TIMES. 

End-of-informat1on 

01 LAB-FEES 

TYPE FLOAT OCCURS 16 TIMES. 


01 BOOKS 

TYPE FLOAT OCCURS 16 TIMES. 


01 MISC-FEES 

TYPE FLOAT OCCURS 16 TIMES. 
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Source Input 

Job statement 

USER statement 
CHARGE statement 
ATTACH(UNIVERS) 
DEFINE(SSLIB/CT=PU 

,M=W) 

DDLF(F5,SB=SSLIB,SC=UNIVERS) 

End-of-record 


SUBSCHEMA AVERAGE,SCHEMA=UNIVERSITY 

ALIAS(REALM) 

CFILE=CURRICULUM 

ALIAS(RECORD) CRECORD=CURR-REC 

- ALIAS(ITEM) 

STUDENT=STUDENT-ID.CURR-REC 

ALIAS(ITEM) 

COURSE=COURSE-ID.CURR-REC 

REALM CFILE 


RECORD CRECORD 

CHARACTER*!4 

IDENT 

CHARACTER*!1 

STUDENT 

CHARACTER*6 COURSE 

REAL GRADE 
END 


SUBSCHEMA COMPARE,SCHEMA-UNIVERSITY 

ALIAS(REALM) 

PFILE=PROFESSOR 

ALIAS(RECORD) 

PRECORD=PROF-REC 

ALIAS(ITEM) 

PROFID=PROF-ID.PROF-REC 

ALIAS(ITEM) 

PNAME=PR0 F-NAME 

ALIAS(REALM) 

CRSFILE=COURSE 

ALIAS(RECORD) 

CRSREC=COURSE-REC 

ALIAS(ITEM) 

CRSID=COURSE-ID.COURSE-REC 

ALIAS(ITEM) 

CRSNAME=COURSE-NAME 

ALIAS(ITEM) 

PR0F=PR0F-ID.COURSE-REC 

ALIAS(ITEM) 

FIELD=ACADEMIC-FIELD 

ALIAS(REALM) 

C FILE=CURRICULUM 

ALIAS(RECORD) 

CRECORD=CURR-REC 

ALIAS(ITEM) 

COURSE=COURSE-ID.CURR-REC 

ALIAS(ITEM) 

CODE=COMPLETE-CODE 

ALIAS(ITEM) 

DATE=COMPLETE-DATE 

REALM PFILE 
REALM CRSFILE 
REALM CFILE 


RECORD PRECORD 

CHARACTERS PROFID 

CHARACTERS 

PNAME 

CHARACTER*20 

FIELD 

RECORD CRSREC 


CHARACTER*6 CRSID 

CHARACTER*20 

CRSNAME 

CHARACTER*8 PROF 

RECORD CRECORD 

CHARACTER*!4 

IDENT 

CHARACTERS COURSE 

CHARACTERS CODE 

CHARACTERS DATE 

REAL GRADE 


RELATION REL3 


RESTRICT CRECORD (CODE .EQ. 'C') 

END 
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SUBSCHEMA RELATION,SCHEMA-UNIVERSITY 


ALIAS(REALM) SFILE=STUDENT 

ALIAS(RECORD) SRECORD=STUDENT-REC 

ALIAS(ITEM) STID=STUDENT-ID.STUDENT-REC 

ALIAS(REALM) CFILE-CURRICULUM 
ALIAS(RECORD) CRECORD=CURR-REC 
ALIAS(ITEM) C$TID=STUDENT-ID.CURR-REC 

ALIAS(ITEM) COURS=COURSE-ID.CURR-REC 

ALIAS(ITEM) PROF=PROF-NAME 
ALIAS(ITEM) CODE=COMPLETE-CODE 
ALIAS(ITEM) DATE=COMPLETE-DATE 

REALM SFILE 
REALM CFILE 

RECORD SRECORD 
CHARACTER*!1 STID 
CHARACTER*20 MAJOR 

RECORD CRECORD 
CHARACTER*!4 IDENT 
CHARACTER*!1 CSTID 
CHARACTER*6 COURS 
REAL GRADE 
CHARACTER CODE 
CHARACTER*8 DATE 
INTEGER UNITS 
RELATION REL! 

RESTRICT CRECORD(CODE•EQ.'C 1 ) 

END 

SUBSCHEMA ADMIS$IONS,$CHEMA=UNIVERSITY 

ALIAS(RECORD) CRSREC-COURSE-REC 
ALIAS(ITEM) CID=COUR$E-ID.COURSE-REC 
ALIAS(ITEM) NAME^COURSE-NAME 
ALIAS(ITEM) PREREQ=PRERE(HJISITE 

ALIAS(REALM) CFILE=CURRICULUM 
ALIAS(RECORD) CURREC=CURR-REC 
ALIAS(ITEM) STUDENT-STUDENT-ID 
ALIAS(ITEM) CCID=COURSE-ID.CURR-REC 
ALIAS(ITEM) CODE=COMPLETE-CODE 

REALM COURSE 
REALM CFILE 

RECORD CRSREC 
CHARACTER*6 CID 
CHARACTER*20 NAME 
CHARACTER*20 SCHOOL 
CHARACTER*6 PREREQ 
INTEGER UNITS 

RECORD CURREC 
CHARACTER*!4 IDENT 
CHARACTER*!! STUDENT 
CHARACTER*6 CCID 
CHARACTER CODE 
END 
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SUBSCHEMA BURSAR,SCHEMA=UNIVERSITY 


ALIAS(RECORD) STREC=STUDENT-REC 
ALIAS(ITEM) STID=STUDENT-ID.STUDENT-REC 
ALIAS(ITEM) NAME=STUDENT-NAME 
ALIAS(ITEM) ADDR=STREET-ADDRESS 
ALIAS(ITEM) ZIP=ZIP-CODE 

ALIAS(REALM) ACCOUNT=ACCOUNTING 

ALIAS(RECORD) ACCTREC=ACCT-REC 

ALIAS(ITEM) ASTID=STUDENT-ID.ACCT-REC 

ALIAS(ITEM) LAB=LAB-FEES 

ALIAS(ITEM) MISC=MISC-FEES 

REALM STUDENT 
REALM ACCOUNT 

RECORD STREC 
CHARACTER*!1 STID 
CHARACTER*30 NAME 
CHARACTER*20 ADDR 
CHARACTER*!0 CITY 
CHARACTER*2 STATE 
CHARACTER*5 ZIP 

RECORD ACCTREC 
CHARACTER*!! ASTID 
REAL TUITION(!6) 

REAL LAB(16) 

REAL BOOKS(16) 

REAL HISC(16) 

RELATION REL2 
END 

End-of-record 
End-of-inforraation 


Compilation Source Listings 


AVERAGE 


* SOURCE LISTING * (8035!) DDLF 1 


0000 ! 

00002 

00003 

00004 

00005 

00006 

00007 

00008 

00009 

00010 

00011 

** WITHIN CFILE 

00012 

** ORDINAL 1 

00013 

★* ORDINAL 2 

00014 

** ORDINAL 3 

00015 

** ORDINAL 4 

00016 


SUBSCHEMA AVERAGE,SCHEMA=UNIVERSITY 

ALIAS(REALM) CFILE=CURRICULUM 
ALIAS(RECORD) CRECORD=CURR-REC 
ALIAS(ITEM) STUDENT=STUDENT-ID.CURR-REC 

ALIAS(ITEM) COURSE=COURSE-ID.CURR-REC 

REALM CFILE 

RECORD CRECORD 


CHARACTERS4 IDENT 
CHARACTER*!1 STUDENT 
CHARACTER*6 COURSE 
REAL GRADE 
END 
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00017 

***** END OF SUB-SCHEMA SOURCE INPUT 


PRIMARY KEY 00012 
ALTERNATE KEY 00013 
ALTERNATE KEY 00014 
ALTERNATE KEY 00015 
***** 


IDENT FOR AREA CFILE 
STUDENT FOR AREA CFILE 
COURSE FOR AREA CFILE 
GRADE FOR AREA CFILE 

RECORD MAPPING IS NEEDED FOR REALM - CFILE 


BEGIN SUB-SCHEMA FILE MAINTENANCE 


SUBSCHEMA CHECKSUM 

AVERAGE 35514310376143061021 


- END OF FILE MAINTENANCE 

DDLF COMPLETE. 0 DIAGNOSTICS. 

476008 CM USED. 0.064 CP SECS. 


COMPARE 


* SOURCE LISTING * (80351) DDLF 


00001 

00002 

00003 

00004 

00005 

00006 

00007 

00008 

00009 

00010 

00011 

00012 

00013 

00014 

00015 

00016 

00017 

00018 

00019 

00020 

00021 

00022 

00023 

00024 

00025 

** WITHIN PFILE 

00026 

** ORDINAL 1 

00027 

** ORDINAL 2 

00028 

00029 

** ORDINAL 3 

00030 

** WITHIN CRSFILE 

00031 

** ORDINAL 1 

00032 

** ORDINAL 2 

00033 

00034 

** ORDINAL 3 


SUBSCHEMA COMPARE,SCHEMA=UNIVERSITY 


ALIAS(REALM) 
ALIAS(RECORD) 
ALIAS(ITEM) 
ALIAS(ITEM) 


PFILE=PROFES$OR 

PRECORD=PROF-REC 

PROFID=PROF-ID.PROF-REC 

PNAME=PROF-NAME 


ALIAS(REALM) 
ALIAS(RECORD) 
ALIAS(ITEM) 
ALIAS(ITEM) 
ALIAS(ITEM) 
ALIAS(ITEM) 


CRSFILE=COURSE 
CRSREC=COURSE-REC 
CRSID=COURSE-ID.COURSE-REC 
CRSNAME=COUR$E-NAME 
PROF=PROF-ID.COURSE-REC 
FIELD=ACADEMIC-FIELD 


ALIAS(REALM) 
ALIAS(RECORD) 
ALIAS(ITEM) 
ALIAS(ITEM) 
ALIAS(ITEM) 


CFILE=CURRICULUM 
CRECORD=CURR-REC 
COURSE=COURS£-ID•CURR-REC 
CODE=COMPLETE-CODE 
DATE=COMPLETE-DATE 


REALM PFILE 
REALM CRSFILE 
REALM CFILE 


RECORD PRECORD 
CHARACTERS PROFID 
CHARACTERS PNAME 
CHARACTER*20 FIELD 


RECORD CRSREC 
CHARACTER*6 CRSID 
CHARACTER*20 CRSNAME 
CHARACTER*8 PROF 


Figure C-2. The FORTRAN Sub-Schema Library (Sheet 4 of 8) 


.2+538. 


C-6 


60483500 A 






00035 

RECORD CRECORD 

** WITHIN CFILE 

00036 

CHARACTERS IDENT 

** ORDINAL 1 

00037 

CHARACTERS COURSE 

** ORDINAL 2 

00038 

CHARACTER*! CODE 

** ORDINAL 3 

00039 

CHARACTER*8 DATE 

** ORDINAL 4 I 

00040 

REAL GRADE 

00041 

** ORDINAL 5 

00042 

RELATION REL3 

PRIMARY KEY 00026 

PROFID FOR AREA PFILE 

ALTERNATE KEY 00028 

FIELD FOR AREA PFILE 

PRIMARY KEY 00031 

CRSID FOR AREA CRSFILE 

ALTERNATE KEY 00033 

PROF FOR AREA CRSFILE 

PRIMARY KEY 00036 

IDENT FOR AREA CFILE 

ALTERNATE KEY 00037 

COURSE FOR AREA CFILE 

ALTERNATE KEY 00040 

GRADE FOR AREA CFILE 

***** 

RECORD MAPPING IS NOT NEEDED FOR REALM - PFILE 

***** 

RECORD MAPPING IS NEEDED FOR REALM - CRSFILE 

***** 

RECORD MAPPING IS NEEDED FOR REALM - CFILE 

00043 

RESTRICT CRECORD (CODE .EG. ’C') 

00044 

END 

00045 1 

***** 

END OF SUB-SCHEMA SOURCE INPUT 

***** 

RELATION STATISTICS ***** 

RELATION 001 

REL3 JOINS AREA - PFILE 

AREA - CRSFILE 

AREA - CFILE 

— 

BEGIN SUB-SCHEMA FILE MAINTENANCE - 

SUBSCHEMA 

CHECKSUM 

COMPARE 

71111404530456653576 


END OF FILE MAINTENANCE - 

DDLF COMPLETE. 

0 DIAGNOSTICS. 

506008 CM USED. 

0.146 CP SECS. 
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RELATION 

★ SOURCE LISTING * (80351) DDLF 1.2+538. 

00001 

SUBSCHEMA RELATION,SCHEMA=UNIVERSITY 

00002 

00003 

ALIAS(REALM) SFILE=STUDENT 

00004 

ALIAS(RECORD) SRECORD=STUDENT-REC 

00005 

ALIAS(ITEM) STID=STUDENT-ID.STUDENT-REC 

00006 

00007 

ALIAS(REALM) CFILE=CURRICULUM 

00008 

ALIAS(RECORD) CRECORD=CURR-REC 

00009 

ALIAS(ITEM) CSTID=STUDENT-ID.CURR-REC 

00010 

ALIAS(ITEM) COURS=COURSE-ID.CURR-REC 

00011 

ALIAS(ITEM) PROF=PROF-NAME 

00012 

ALIAS(ITEM) CODE=COMPLETE-CODE 

00013 

ALIAS(ITEM) DATE=COMPLETE-DATE 

00014 

00015 

REALM SFILE 

00016 

REALM CFILE 

00017 

00018 

RECORD SRECORD 

** WITHIN SFILE 

00019 

CHARACTER*!1 STID 

** ORDINAL 1 

00020 

CHARACTER*20 MAJOR 

00021 

** ORDINAL 2 

00022 

RECORD CRECORD 

** WITHIN CFILE 

00023 

CHARACTER*!4 IDENT 

** ORDINAL 1 

00024 

CHARACTERS 1 CSTID 

** ORDINAL 2 

00025 

CHARACTER*6 COURS 

** ORDINAL 3 

00026 

REAL GRADE 

** ORDINAL 4 

00027 

CHARACTER CODE 

** ORDINAL 5 

00028 

CHARACTERS DATE 

** ORDINAL 6 

00029 

INTEGER UNITS 

** ORDINAL 7 

00030 

RELATION REL1 

PRIMARY KEY 00019 

STID FOR AREA SFILE 

ALTERNATE KEY 00020 

MAJOR FOR AREA SFILE 

PRIMARY KEY 00023 

IDENT FOR AREA CFILE 

ALTERNATE KEY 00024 

CSTID FOR AREA CFILE 

ALTERNATE KEY 00025 

COURS FOR AREA CFILE 

ALTERNATE KEY 00026 

GRADE FOR AREA CFILE 

***** 

RECORD MAPPING IS NEEDED FOR REALM - SFILE 

***** 

RECORD MAPPING IS NEEDED FOR REALM - CFILE 

00031 

RESTRICT CRECORD(CODE.EQ.'C') 

00032 

END 

00033 

***** 

END OF SUB-SCHEMA SOURCE INPUT 

***** 

RELATION STATISTICS ***** 

RELATION 001 

REL1 JOINS AREA - SFILE 

AREA - CFILE 

— 

BEGIN SUB-SCHEMA FILE MAINTENANCE - 

SUBSCHEMA 

CHECKSUM 

RELATION 

76710464332261536703 

— 

END OF FILE MAINTENANCE - 

DDLF COMPLETE. 

0 DIAGNOSTICS. 

50500B CM USED. 

0.128 CP SECS. 
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ADMISSIONS 


* SOURCE LISTING * (80351) DDLF 1.2+538 


3483500 A 



00001 


SUBSCHEMA ADMISSIONS,SCHEMA=UNIVERSITY 


00002 




00003 


ALIAS(RECORD) CRSREC=COURSE-REC 


00004 


ALIAS(ITEM) CID=COURSE-ID.COURSE-REC 


00005 


ALIAS(ITEM) NAME=COURSE-NAME 


00006 


ALIAS(ITEM) PREREQ=PREREQUISITE 


00007 




00008 


ALIAS(REALM) CFILE=CURRICULUM 


00009 


ALIAS(RECORD) CURREC=CURR-REC 


00010 


ALIAS(ITEM) STUDENT=STUDENT-ID 


00011 


ALIAS(ITEM) CCID=COURSE-ID.CURR-REC 


00012 


ALIAS(ITEM) CODE=COMPLETE-CODE 


00013 




00014 


REALM COURSE 


00015 


REALM CFILE 


00016 




00017 


RECORD CRSREC 

** WITHIN COURSE 




00018 


CHARACTERS CID 

** ORDINAL 

1 




00019 


CHARACTER*20 NAME 

** ORDINAL 

2 




00020 


CHARACTERS!) SCHOOL 

** ORDINAL 

3 




00021 


CHARACTERS PREREQ 

** ORDINAL 

4 




00022 


INTEGER UNITS 


00023 



** ORDINAL 

5 




00024 


RECORD CURREC 

** WITHIN CFILE 




00025 


CHARACTERS 4 IDENT 

** ORDINAL 

1 




00026 


CHARACTERS 1 STUDENT 

** ORDINAL 

2 




00027 


CHARACTERS CCID 

** ORDINAL 

3 




00028 


CHARACTER CODE 

** ORDINAL 

4 




00029 


END 


00030 




***** 

END OF 

SUB-SCHEMA SOURCE INPUT 

PRIMARY KEY 

00018 

CID FOR AREA COURSE 

PRIMARY KEY 

00025 

IDENT 

FOR AREA CFILE 

ALTERNATE KEY 

00026 

STUDENT FOR AREA CFILE 

ALTERNATE KEY 

00027 

CCID FOR AREA CFILE 


***** 

RECORD 

MAPPING IS NEEDED FOR REALM - COURSE 


***** 

RECORD 

MAPPING IS NEEDED FOR REALM - CFILE 


- BEGIN SUB-SCHEMA FILE MAINTENANCE 

SUBSCHEMA CHECKSUM 

ADMISSIONS 56065313377542307610 


DDLF COMPLETE. 
50000B CM USED. 


END OF FILE MAINTENANCE 
0 DIAGNOSTICS. 

0.109 CP SECS. 
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BURSAR 


★ SOURCE LISTING * (80351) DDLF 1.2+538 



00001 

00002 

SUBSCHEMA BURSAR,SCHEMA=UNIVERSITY 


00003 

ALIAS(RECORD) STREC=STUDENT-REC 


00004 

ALIAS(ITEM) STID=STUDENT-ID.STUDENT-REC 


00005 

ALIAS(ITEM) NAME=STUDENT-NAME 


00006 

ALIAS(ITEM) ADDR=STREET-ADDRESS 


00007 

00008 

ALIAS(ITEM) ZIP=ZIP-CODE 


00009 

ALIAS(REALM) ACCOUNT=ACCOUNTING 


00010 

ALIAS(RECORD) ACCTREC=ACCT-REC 


00011 

ALIAS(ITEM) ASTID=STUDENT-ID.ACCT-REC 


00012 

ALIAS(ITEM) LAB=LAB-FEES 


00013 

00014 

ALIAS(ITEM) MISC=MISC-FEES 


00015 

REALM STUDENT 


00016 

00017 

REALM ACCOUNT 


Q0018 

RECORD STREC 

** WITHIN STUDENT 



00019 

CHARACTERS 1 STID 

** ORDINAL 

1 



00020 

CHARACTER*30 NAME 

** ORDINAL 

2 



00021 

CHARACTER*20 ADDR 

** ORDINAL 

3 



00022 

CHARACTERS0 CITY 

** ORDINAL 

4 



00023 

CHARACTER*2 STATE 

** ORDINAL 

5 



00024 

00025 

CHARACTERS ZIP 

** ORDINAL 

6 



00026 

RECORD ACCTREC 

** WITHIN ACCOUNT 



00027 

CHARACTERS 1 ASTID 

** ORDINAL 

1 



00028 

REAL TUITION(16) 

** ORDINAL 

2 



00029 

REAL LA8(16) 

** ORDINAL 

3 



00030 

REAL BOOKS(16) 

** ORDINAL 

4 



00031 

00032 

REAL MISC(16) 

** ORDINAL 

5 



00033 

RELATION REL2 

PRIMARY KEY 

00019 

STID FOR AREA STUDENT 

PRIMARY KEY 

00027 

ASTID FOR AREA ACCOUNT 


***** 

RECORD MAPPING IS NEEDED FOR REALM - STUDENT 


***** 

RECORD MAPPING IS NOT NEEDED FOR REALM - ACCOUNT 


00034 

END 


***** 

END OF SUB-SCHEMA SOURCE INPUT 


***** 

RELATION STATISTICS ***** 

RELATION 001 


REL2 JOINS AREA - STUDENT 

AREA - ACCOUNT 


—- 

BEGIN SUB-SCHEMA FILE MAINTENANCE 

— 

SUBSCHEMA 

CHECKSUM 


BURSAR 

16643753141007716046 


— 

END OF FILE MAINTENANCE - 


DDLF COMPLETE. 

0 DIAGNOSTICS. 


50500B CM USED. 

0.107 CP SECS. 
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Job statement 


RECORD CRSREC 

USER statement 


CHARACTERS CRSID 

CHARGE statement 


CHARACTER*20 CRSNAME 

ATTACH,UNIVERS. 


CHARACTER*20 SCHOOL 

DEFINE(CREATES/CT=PU,M=W) 

CHARACTERS PROF 

DDLF(F5„SB=CREATES, 

SC=UNIVERS) 

CHARACTERS PREREQ 

End-of-Record 


INTEGER UNITS 

SUBSCHEMA CREATES / SCHEMA=UNIVERSITY 

RECORD STREC 

ALIAS(REALM) 

PFILE=PROFESSOR 

CHARACTER*!1 STID 
CHARACTER*30 NAME 

ALIAS (RECORD) 

PRECORD=PROF-REC 

CHARACTER*20 ADDR 

ALIAS(ITEM) 

PROFID=PR0F-ID.PROF-REC 

CHARACTERS0 CITY 

ALIAS(ITEM) 

PNAME=PROF-NAME 

CHARACTERS STATE 

ALIAS(ITEM) 

FIELD=ACADEMIC-FIELD 

CHARACTERS ZIP 

ALIAS(REALM) 

CRSFILE=COURSE 

CHARACTERS 2 PHONE 
CHARACTERS) MAJOR 

ALIAS(RECORD) 

CRSREC=COURSE-REC 


ALIAS (ITEM) 

CRSID=COURSE-ID.COURSE-REC 

RECORD CRECORD 

ALIAS(ITEM) 

CRSNAME=COURSE-NAME 

CHARACTERS A IDENT 

ALIAS(ITEM) 

PROF=PROF-ID.COURSE-REC 

CHARACTERS 1 CSTID 

ALIAS(ITEM) 

PREREQ=PREREQUISITE 

CHARACTERS COURSE 

ALIAS(RECORD) 

STREC=STUDENT-REC 

REAL GRADE 

CHARACTERS CODE 

ALIAS(ITEM) 

STID=STUDENT-ID.STUDENT-REC 

CHARACTERS DATE 

ALIAS(ITEM) 

NAME=STUDENT-NAME 

INTEGER CRUNITS 

ALIAS(ITEM) 

ADDR=STREET-ADDRESS 


ALIAS(ITEM) 

ZIP=ZIP-CODE 

RECORD ACCTREC 

ALIAS(REALM) 

CFILE=CURRICULUM 

CHARACTERS 1 ASTID 
REAL TUITION (16) 

ALIAS(RECORD) 

CRECORD=CURR-REC 

REAL LAB(16) 

ALIAS(ITEM) 

CSTID=STUDENT-ID.CURR-REC 

REAL BOOKS (16) 

ALIAS(ITEM) 

COURSE=COURSE-ID.CURR-REC 

REAL MISC(16) 

ALIAS(ITEM) 

CODE=COMPLETE-CODE 


ALIAS(ITEM) 

DATE=COMPLETE-DATE 

END 

ALIAS(ITEM) 

CRUNITS=UNITS.CURR-REC 

End-of-Record 

ALIAS(REALM) 

ACCOUNT=ACCOUNTING 

End-of-Information 

ALIAS(RECORD) 

ACCTREC=ACCT-REC 


ALIAS(ITEM) 

ASTID=STUDENT-ID.ACCT-REC 


ALIAS(ITEM) 

LAB=LAB-FEES 


ALIAS(ITEM) 

MISC=MISC-FEES 


REALM PFILE 

REALM CRSFILE 

REALM STUDENT 

REALM CFILE 

REALM ACCOUNT 

RECORD PRECORD 


CHARACTERS PROFID 


CHARACTERS!) PNAME 


CHARACTER*20 

FIELD 
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Job statement 

AREA NAME IS CURRICULUM 

USER statement 

PFN IS "CURRICU" UN IS "DBID001" 

CHARGE statement 

INDEX FILE ASSIGNED 

DEFINE(MSTRDIR/CT=PU) 

PFN "CRNDX" UN IS "DBID001". 

ATTACH(UNIVERS) 


ATTACH(SSLIB) 

AREA NAME IS ACCOUNTING 

ATTACH(CREATES) 

PFN IS "ACCOUNT" UN IS "DBID001". 

DBMSTRD(NMD=HSTRDIR,LD) 


End-of-record 

SUBSCHEMA NAME IS AVERAGE 


FILE NAME IS SSLIB. 

SCHEMA NAME IS UNIVERSITY 


FILE NAME IS UNIVERS 

SUBSCHEMA NAME IS COMPARE 

TRANSACTION RECOVERY FILE 

FILE NAME IS SSLIB. 

PFN IS "FTNTRF" UN IS "DBID001" 


RESTART IDENTIFIER FILE 

SUBSCHEMA NAME IS RELATION 

PFN IS "FTNRIF" UN IS "DBID001". 

FILE NAME IS SSLIB. 

AREA NAME IS PROFESSOR 

SUBSCHEMA NAME IS ADMISSIONS 

PFN IS "PROFESS" UN IS "DBID001" 

FILE NAME IS SSLIB. 

INDEX FILE ASSIGNED 


PFN "PNDX" UN IS "DBID001 

SUBSCHEMA NAME IS BURSAR 


FILE NAME IS SSLIB. 

AREA NAME IS COURSE 


PFN IS "COURSE" UN IS "DBID001" 

SUBSCHEMA NAME IS CREATES 

INDEX FILE ASSIGNED 

FILE NAME IS CREATES. 

PFN "CRSNDX" UN IS "DBID001". 

End-of-Record 

AREA NAME IS STUDENT 

End-of-Information 

PFN IS "STUDENT” UN IS "DBID001" 


INDEX FILE ASSIGNED 


PFN "SNDX" UN IS "DBID001". 


Figure C-4. The Master Directory Build 

Job Statement 


USER statement 


CHARGE statement 


DEFINE,FTNTRF1,FTNRIF/CT=PU. 

RETURN,FTNTR F1,FTNRIF. 

ATTACH,MSTRDIR. 


DBREC. 


End-of-Record 


SCHEMA NAME IS UNIVERSITY 

ALLOCATE 


TRANSACTION RECOVERY FILE IS FTNTRF1 

RESTART IDENTIFIER FILE IS FTNRIF 

End-of-Record 


End-of-Information 



Figure C-5. Log File Initialization 
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Job statement 
USER statement 
CHARGE statement 
ATTACH(CREATES) 

ATTACH(PDATA,CRSDATA,SDATA,CDATA,ACCDATA) 

DEFINE(PROFESS,PNDX/CT =PU,M=W) 

DEFINE(COURSE,CRSNDX/CT=PU,M=W) 

DEFINE(STUDENT,SNDX/CT=PU,M=W) 

DEFINE(CURRICU,CRNDX/CT=PU,M=W) 

DEFINE(ACCOUNT/CT=PU,M=W) 

RETURN(PROFESS,PNDX,COURSE,CRSNDX) 

RETURN(STUDENT,SNDX,CURRICU,CRNDX,ACCOUNT) 

DML(LV=F5,SB=CREATES) 

FTN5(I=DHLOUT,DB=0) 

LIBRARY,DHSLIB. 

CDCSBTF(LGO/MDPFN=MSTRDIR,UN=xx) 

End-of-record 

PROGRAM BUILD 
SUBSCHEMA(CREATES) 

INVOKE 

PRIVACY(CFILE,M0DE=0,PRIVACY=’XX99') 

OPEN(PFILE,MODE=0,ERR=900) 

OPEN(1,FILE='PDATA') 

100 READ(1,FMT=’(A8,A30,A20) , ,END=199) PROFID,PNAME,FIELD 
WRITE(PFILE,ERR=900) 

GOTO 100 

199 CLOSE(PFILE,ERR=900) 

CLOSE (1,STATUS='DELETE') 

OPEN(CRSFILE,M0DE=O,ERR=900) 

OPEN(1,FILE= * CRSDATA') 

200 READ(1,FMT='(A6,A20,A20,A8,A6,I2)' ,END=299> CRSID,CRSNAME,SCHOOL 
+ PROF,PREREQ,UNITS 

WRITE(CRSFIL£,ERR=900) 

GOTO 200 

299 CL0SE(CRSFILE,ERR=900) 

CLOSE(1,STATUS=’DELETE') 

OPEN(STUDENT,N0DE=0,ERR=900) 

0PEN(1,FILE='SDATA') 

300 READ(1,FMT='(All,A30,A20,A10)',END=399) STID,NAME,ADDR,CITY 
READ(1,FMT='(A2,A5,A12,A20)', END=399) STATE,ZIP,PHONE,MAJOR 
WRITE(STUDENT,ERR=900) 

GOTO 300 

399 C LOSE(STUDENT,ERR =900) 

CLOSE (1 ,STATUS='DELETE •) 

OPEN(CFILE,M0DE=O,ERR=900) 

0PEN(1,FILE='CDATA') 

400 READ(1,FMT='(A14,A11,A6,F3.1,A1,A8,F3.1)' ,END=499) IDENT,CSTID, 

+ COURSE,GRADE,CODE,DATE,CRUNITS 

WRITE(CFILE,ERR=900) 

GOTO 400 

499 CL0SE(CFILE,ERR=900) 

CL0SE(1 ,STATUS=* DELETE') 

0PEN(ACCOUNT,M0DE=0,ERR=900) 

DO 510 1=1,16 
TUIT ION (I) =0.0 
LAB(I)=0.0 
BOOKS(I)=0.0 
510 MISC(I)=0.0 

OPENd ,FILE='ACCDATA') 

550 READ(1,FMT='(All)',END=599) ASTID 
WRITE(ACCOUNT,ERR=900) 

GOTO 550 

599 CLOSE(ACCOUNT,ERR=900) 

CLOSE(1,STATUS='DELETE') 

900 TERMINATE 
END 

End-of-Reeord 
End-of-Information 


Figure C-6. The FORTRAN Data Base Creation Program (Sheet 1 of 3) 
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File PDftTA— (Input data for PFILE) 


CRLN0080CARLIN, W.L. 
DVS00575DAVIS, M.E. 
JCKSN750JACKSON, U.B. 
JMS00160JAMES, H.L. 
MLN00840MALONE, R.E. 
RSS00860ROSS, U.R. 
SMTH0455SMITH, P.R. 
ULSN0855WILS0N,G.R. 
YMD00170YMA0A, J.V. 


HISTORY 

PSYCHOLOGY 

BUSINESS 

PSYCHOLOGY 

HISTORY 

BUSINESS 

MATHEMATICS 

CHEMISTRY 

BUSINESS 


File CRSDATA--(Input data for CRSFILE) 


CHM103BI0CHEMISTRY SCIENCE 

CHM005QUANTITATIVE ANAL SCIENCE 

CHM110LINEAR OPTIMIZATION SCIENCE 

PSY136SOCIAL PSYCHOLOGY LIBERAL ARTS 

PSY002GENERAL PSYCHOLOGY LIBERAL ARTS 

PSY003PSYCHONOMICS LIBERAL ARTS 

HIS103GREEK HISTORY LIBERAL ARTS 

BUS017C0NSUMER LAW BUSINESS ADMIN 

BUS001ACCOUNTING I BUSINESS ADMIN 

BUS002ACC0UNTING II BUSINESS ADMIN 

MATH10C0LLEGE ALGEBRA SCIENCE 

File SDATA—(Input data for STUDENT) 

CRLN0080CHM0053 
ULSN0855N/A 4 
WLSN0855MATH103 

JMS00160N/A 3 

JMS00160N/A 3 

DVS00575PSY0023 

MLN00840N/A 3 

JCKSN750N/A 3 

YND00170N/A 3 
RSS00860BUS0013 
SMTH0455N/A 3 

122-13-6704MALTER HILL 

MN55112612-143-1760HIST0RY 


1960 MONTANA ST. 

MINNEAPOLI 

100-22-5860GUY RICHARDS 
MN55440612-715-9187BI0L0GY 


143 E. LAKE BLVD. 

MINNEAPOLI 

124-33-5780BARBARA YOUNG 

MN55440612-731-4632HISTORY 


413 MAPLE AVE. 

MINNEAPOLI 

120-44-3760J ERI ADAMS 

MN55112612-625-7913CHEMISTRY 


1400 W. OAK LANES 

MINNEAPOLI 

553-89-2021 PAUL JOHNSON 

MN55104612-649-1377PSYCH0L0GY 


137 MARKET ST. 

MINNEAPOLI 

687-14-21OOPATRICIA ANDREWS 

MN55112612-436-8750BIOLOGY 


100 KAUREL DR. 

MINNEAPOLI 

197-11-2140CAREN NIELSON 

MN55104612-136-9800CHEMISTRY 


12 MORRIS ST. 

MINNEAPOLI 

678-12-1144MARK PETERSEN 

MN55112612-143-9877PSYCHOLOGY 


1372 PARKVIEW DR. 

MINNEAPOLI 

387-14-1232LLOYD DAVIS 
MN55104612-993-4773CHEMISTRY 


692 FIRST ST. APT. 

1MINNEAPOLI 

437-56-8943JANET ANDERSON 

MN55112612-997-6160BIOLOGY 


986 SINCLAIRE AVE. 

MINNEAPOLI 


Figure C-6. The FORTRAN Data Base Creation Program (Sheet 2 of 3) 
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File CDATA—(Input data for CFILE) 

122-13-6704-01122-13-6704HIS1034-0C09/22/803.0 
122-13-6704-02122-13-6704PSY1360.01 3.0 
100-22-5860-011Q0-22-5860CHM1033.QC 05/30/793.0 
100-22-5860-02100-22-5860CHM0054.OC09/22/794.0 
100-22-5860-03100-22-5860MATH103.5C05/18/793.0 
100-22-5860-04100-22-5860PSY0020.01 3.0 
124-33-5780-01124-33-5780HIS1033.5C 09/22/803.0 
124-33-5780-02124-33-5780BUS0014.OC02/24/803.0 
124-33-5780-03124-33-5780BUS0024.0C09/22/803.0 
120-44-3760-01120-44-3760CHM0052.0C09/22/794.0 
120-44-3760-02120-44-3760CHM1033.0C05/30/803.0 
120-44-3760-03120-44-3760MATH104.0C05/30/803.0 
120-44-3760-04120-44-3760CHM1103.5C09/22/803.0 
553-89-2021-01553-89-2021PSY1363.5C05/30/803.0 
553-89-2021-02553-89-2021PSY0024.0C05/30/803.0 
553-89-2021-03553-89-2021PSY0033.5C09/22/803.0 
687-14-2100-01687-14-21OQC HM0054.OC 09/22/794.0 
687-14-2100-02687-14-21OOCHM1O33.5C05/3O/8O3.O 
687-14-2100-03687-14-21QOM ATH104.OC 05/30/803.0 
687-14-2100-04687-14-21OOC HM1104.0C05/30/803.0 
197-11-2140-01197-11-2140CHM0053.0C05/30/804.0 
197-11-2140-02197-11-214QCHM1033.5C09/22/803.0 
197-11-2140-03197-11-2140CHM1104.OC09/22/803.0 
197-11-2140-04197-11-2140MATH104.0C05/30/803.0 
678-12-1144-01678-12-1144PSY1364.0C05/30/803.0 
678-12-1144-02678-12-1144BUS 0174.QC05/30/803.0 


678-12-1144-03678-12-1144HIS1030.01 3.0 
387-14-1232-01387-14-1232MATH100.01 3.0 
387-14-1232-02387-14-1232CHMG050.01 4.0 
387-14-1232-03387-14-1232PSY1360.01 3.0 
387-14-1232-04387-14-1232BUS0170.01 3.0 


437-56-8943-01437-56-8943MATH103.0C05/30/803.0 
437-56-8943-02437-56-8943CHM0053.5C05/30/804.0 
437-56-8943-03437-56-8943PSY 0023.5C 05/30/803.0 


File ACCDATA—(Input data for ACCOUNT) 

122-13-6704 

100-22-5860 

124-33-5780 

120-44-3760 

553-89-2021 

687-14-2100 

197-11-2140 

678-12-1144 

387-14-1232 

437-56-8943 


Figure C-6. 


The FORTRAN Data Base Creation Program (Sheet 3 of 3) 
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